Daniels advice is actually the best that you can get. It will give you the smallest chance of corruption due out of order journal commits that caching can cause.
js On 10/31/06, Daniel Iliev <[EMAIL PROTECTED]> wrote:
Alan McKinnon wrote: > On Tuesday 31 October 2006 11:04, Uwe Thiem wrote: > >> On 31 October 2006 09:17, Alan McKinnon wrote: >> >>> I find it useful to keep in mind that XFS is a file-system (i.e. a >>> system for files), and not necessarily a severly disk-bound >>> filesystem >>> >> Would you mind to elaborate on this? I simply do not get your point. >> > > Historically SGI was very strong in graphics, and those applicatiosn > tended to generate massive amounts of temporary files that had a short > life and only the final version needs to be written to persistent > storage, very well suited to aggressive caching and other similar > speedups. > > SGI's engineers could get away with this because they could guarantee > that power loss to the machine wouldn't happen, so the potential data > loss on a power outage didn't happen either. This sounds a bit weird to > those of us raised on Intel where we pay close attention to getting > everything on disk ASAP with as little performance loss as possible, > but it's a perfectly reasonable system for an engineer to implement on > the kind of hardware SGI were building. > > That's why I say XFS is designed to not be tightly bound to the physical > disk if the admin chooses to set it up that way, and the file system > becomes more of a collection of directories and files that might never > even be stored on a disk at all > > alan > "..we pay close attention to getting everything on disk ASAP with as little performance loss as possible.." Then I would propose you to use "hdparm -W0 /dev/(what-ever)" to disable the write caching (no matter which FS you use). Nothing can give 100% guarantee against power failure. -- Best regards, Daniel -- gentoo-user@gentoo.org mailing list
-- gentoo-user@gentoo.org mailing list
