Re: AW: Re: New Linux xfs/reiser file systems

From: Giles Lean <giles(at)nemeton(dot)com(dot)au>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "'Lincoln Yeoh'" <lyeoh(at)pop(dot)jaring(dot)my>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AW: Re: New Linux xfs/reiser file systems
Date: 2001-05-07 22:32:31
Message-ID: 131.989274751@nemeton.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 2. The allocation time for raw devices is by far better (near
> instantaneous) than creating preallocated files in a
> fs. Providing 1 Tb of raw devices is a task of minutes,
> creating 1 Tb filsystems with preallocated 2 Gb files is a
> task of hours at best.

Filesystem dependent, surely? Veritas' VxFS can create filesystems
quickly, and quickly preallocate space for the files. If you actually
want to write data into the files that would take longer. :)

Creating a 1TB UFS filesystem might take a while, and UFS doesn't
support pre-allocation of space as far as I know so creating 2GB files
would take time too. Perhaps hours. :-(

> 3. absolute control over writes and page location (you don't want
> interleaved pages)

As well as a filesystem, most large systems I'm familiar with use
volume management software (VxVM, LVM, ...) and their "disks" will be
allocated space on disk arrays.

These additional layers aren't arguments against simplifying the
filesystem layer, but they sure will complicate measurement and
tuning. :-)

Regards,

Giles

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2001-05-07 22:44:55 Re: A problem with new pg_dump
Previous Message Robert Hentosh 2001-05-07 22:23:18 Re: backend dies on 7.1.1 loading large datamodel.