xfs options

Hi :)

I have a 7tb XFS filesystem. The partition is supposed to stock big files between 2mo and 50mo. Quite no small files.

So i'm trying to adapt the mount option to what I need, and what I need is security. I want to be sure that NONE of the files will be lost, even if there's a power failure. For now, I just tried the noatime mount option, I know there is a lot of options, but I don't really understand what they stand for.

Do you have any suggestion to make my filesystem safer ?

Thanks

Amandine

Put the system and array on a UPS.

There are also some other tweaks, but nothing is as important as putting it on a UPS.

Justin.

Le Mon, 12 Nov 2007 13:19:57 +0100
Amandine AUPETIT <[email protected]> écrivait:

Unfortunately there isn't any such option. A power failure may be the cause of lost files on any filesystem.

Use redundant power supplies, and UPS; and make backups. Backups, backups, and backups. Keep a copy (with rsync or rsnapshot) on a similar server as your main backup, and a backup on tape. If your data is precious, JUST MAKE BACKUPS.

----------------------------------------
Emmanuel Florac     |   Intellique
----------------------------------------

amandine> Hi :) I have a 7tb XFS filesystem. [ ... ]

We dearly hope that you are using a 64 bit kernel, BTW.

amandine> So i'm trying to adapt the mount option to what I amandine> need, and what I need is security. I want to be sure amandine> that NONE of the files will be lost, even if there's a amandine> power failure.

That's a very difficult goal, and one that requires quite a lot of effort and choosing and testing carefully which hardware components you use and carefully writing your applications.

amandine> For now, I just tried the noatime mount option, I know amandine> there is a lot of options, but I don't really amandine> understand what they stand for.

Then you are not yet in position to even judge whether the following points make sense :-).

amandine> Do you have any suggestion to make my filesystem safer amandine> ?

Making your *filesystem* safer seems a bit pointless to me, what seems to matter to you is "NONE of the files will be lost", and as to that I am assuming that you mean that even if the file has just been written.

Then the most important and essential thing is to ensure that that whole storage chain (application, kernel, host adapter, disk drive) supports disabling (or flushing) their caches, and that every element of the chain returns and passes up reliable success or error indications.

Achieving this is not at all simple; many manufacturers do not supply this information about their products, or they give it wrong, or anyhow the implementation is buggy no matter what the documentation says. Finding a storage chain that can reliably flush data from an application to the storage medium or return a reliable error indication if that fails is far from easy.

Anyhow, in particular it is very important that the application writing the files avoid the use of caching (e.g. no use of 'stdio') or use software barriers (e.g. 'fflush' and 'fsync') at the right times (whuch can be just after every write).

Then by far the safest way to setup things, if the above conditions have been met, is to disable write caching everywhere:

* To disable caching in the host adapter/HBA, there is usually an option in the BIOS/fw.

* To disable caching in the individual disks, use 'hdparm -W0' or equivalent.

* To disable kernel caching, mount the filesystem with '-o sync'.

This will make writes *much* slower (typically at least ten times slower), but it is safe (except that partial writes may still fail, and to prevent that battery backup for every element of the storage chain is needed).

If the decrease in speed is too much, there are less safe but but still fairly good approaches based on using periodic write barriers instead of simply disabling caching.

This requires ensuring that the whole storage chain support fine or coarse grained write barriers with proper error reporting, which again is far from trivial, and in addition there must be sufficient battery backup for every element of the storage chain in which data may be cached until the write barrier is exercised.

This thread may be interesting:

http://OSS.SGI.com/archives/xfs/2007-03/msg00157.html

And perhaps these FAQs:

http://OSS.SGI.com/projects/xfs/faq.html#wcache