Re: AW: AW: Re: New Linux xfs/reiser file systems
От | Giles Lean |
---|---|
Тема | Re: AW: AW: Re: New Linux xfs/reiser file systems |
Дата | |
Msg-id | 882.989312546@nemeton.com.au обсуждение исходный текст |
Ответ на | AW: AW: Re: New Linux xfs/reiser file systems (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
> > 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 intothe file. This space cannot be allocated to other files in the file system. VxFS prevents any unexpected out-of-spacecondition on the file system by ensuring that a file's required space will be associated with the file beforeit 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
В списке pgsql-hackers по дате отправления: