xfs options

xfs options

[Amandine AUPETIT]

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

Re: xfs options

[Justin Piszcz]

On Mon, 12 Nov 2007, Amandine AUPETIT wrote:

> 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.

Re: xfs options

[Emmanuel Florac]

Le Mon, 12 Nov 2007 13:19:57 +0100
Amandine AUPETIT <amandine@jamendo.com> écrivait:

> 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.

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

> 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 ?
> 

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
----------------------------------------

Re: xfs options

[Peter Grandi]

>>> On Mon, 12 Nov 2007 13:19:57 +0100, Amandine AUPETIT
>>> <amandine@jamendo.com> said:

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