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

> > Filesystem dependent, surely? Veritas' VxFS can create filesystems
> > quickly, and quickly preallocate space for the files.
>
> And you are sure, that this does not create a sparse file, which is exactly
> what we do not want ? Can you name one other example ?

http://docs.hp.com//hpux/onlinedocs/B3929-90011/00/00/35-con.html#s3-2

Reservation: Preallocating Space to a File

VxFS makes it possible to preallocate space to a file at the time
of the request rather than when data is written into the
file. This space cannot be allocated to other files in the file
system. VxFS prevents any unexpected out-of-space condition on the
file system by ensuring that a file's required space will be
associated with the file before it is required.

I can't name another example -- I'm not familiar with what IBM's JFS
or SGI's XFS filesytems are capable of doing.

> Of course. My thinking has long switched to volume groups and logical
> volumes. This however does not alter the fact, that one LV can be
> regarded as one mainly contiguous (is that the word ?) block on disk
> for optimization issues. When reading a logical volume sequentially
> head movement will be minimal.

I'm no storage guru, but I'd certainly hope that sequential reads were
"efficient" on just about any storage device.

My mild concern is that any model of storage system behaviour that
includes "head movement" is inadequate for anything but small systems,
and is challenged for them by the presence of caches everywhere.

A storage array such as those made by Hitachi and EMC will have SCSI
LUNs (aka "disks") that are sized and configured by software inside
the storage device.

Good performance on such storage systems might depend on keeping as
much work up to it as possible, to let the device determine what order
to service the requests. Attempts to minimise "head movement" may
hurt, not help. But as I said, I'm no storage guru, and I'm not a
performance consultant either. :-)

Regards,

Giles