filesystems (was Data Recovery: professionals familiar with ext3)

[Daniel Mons]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Gear wrote:
> I started using XFS on my backup drives about 2 years ago when i heard
> that it was good for very large file systems.  I have not been
> impressed.  Every time i've put XFS on an external USB or eSATA drive
> (which is what i use for my backups), i have had a severe corruption
> resulting in backup data loss, at least once every 3-6 months.  The most
> recent was earlier this week.  XFS check and repair times are hideously
> long on these drives.
> 
> I don't know why this is, but it could be something to do with the
> Linux/Irix translation layer that XFS requires, or it could be something
> to do with the very large number of hard links in my backup file system
> (i use rsnapshot).  Regardless, i intend to get rid of my XFS file
> systems as soon as my new 1 TB backup disks arrive :-).
> 
> Disclaimer: I have nothing against XFS in principle.  I just haven't had
> good reliability from it.

My experience is to the contrary.  For example:  Running an 8-disk Linux
software RAID5 set serving 3TB to a small film / visual effects studio
client of mine (20 users on mixed mac/linux/windows, plus another 30
render nodes running all Ubuntu Linux, all served up by NFS/Samba3/LDAP).

LVM2 sits on the raid set, with XFS on everything.  Their main file set
is 2.4TB, and is hammered pretty heavily during production (rendering
even a few minutes of 1080p or 2K uncompressed footage through Apple
Shake will touch a lot of files and move around a lot of data).
Performance is great, and reliability has been fine.  They use rsnapshot
also, with no issues.

They had one instance where a SATA controller blew, and took out 2 disks
of the RAID5 set.  XFS stopped all writes immediately.  After replacing
the controller, I could force-add the 2 disks back into the set and
manually mark them as clean. From there I initiated a RAID5 check, and
all data came back clean.  10 points for XFS and Linux software RAID
combined, doing what proprietary controllers and other file systems
would have failed at.

In your setup above, I can only think that the constant removal of the
disk is potentially causing the issue (I've not used XFS on removable
disks, which is a point of difference).  I would try to ensure the
following:

1) You are manually issuing a "sync" command to flush write buffers
immediately before and immediately after unmounting the partitions (yes,
umount is supposed to do that, but just for sanity's sake).  Script it
to be safe.

2) If the drive is in your fstab, ensure that it's not set to check
errors on mount (ie: the fifth and sixth fields [fs_freq and fs_passno]
are both set to "0" - see "man fstab" for more)

3) Unless you specifically need access time stamps, mount the partition
with the "noatime" option.  99% of users I know don't need atime stamps,
and mounting with the noatime flag can reduce disk writes, I/O and
general mount/unmount faults by a dramatic amount.  This is particularly
true if you are a database user (any database - MySQL, Postgres, SQLite,
or proprietary stuff).  Tagging the disk with a date stamp every time
someone opens the file for read is not really necessary unless you have
very specific security requirements in your business.  All other
timestamps (including create and modify) are left alone by "noatime",
and they work as expected.

I've found XFS to be exceptionally reliable, and much faster than ext3
for both small and large files in large numbers (I have never bothered
with ReiserFS for real world production data, as there are far too many
complaints from high-end users about it).  I have fewer clients in
number who actually use XFS, but I can safely say that it's responsible
for more actual data storage (measured in bytes) under my control than
any other filesystem.

I hope some of that helps you track down your issues successfully.

- -Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFITzbYeFJDv0P9Qb8RAtZrAKCcV9qIZp6JOCPaEbN//zbDQwVyWwCggL4+
uD3Co+M8zND81PbO+9vjzXw=
=sVqr
-----END PGP SIGNATURE-----