Questions about XFS

Hi,

I have a few simple questions regarding the XFS file system. I built a new small server here (commodity hardware, x86-64) and I've installed 32-bit openSUSE 10.2 on it. After the system was installed, configured and up and running, it hung while I was browsing with Firefox. The only thing I could do was to press the reset button on the computer. After the reboot, when I opened Firefox again, I noticed that all my bookmarks were gone. Those bookmarks were imported from my desktop machine a few days after I configured the new server.

All file systems on this new server are XFS because I heard good things about it and it generally performs better in database operations compared to other file systems available for Linux. However, I was pretty surprised that when I had to reset the machine because it hung for some reason, all the bookmarks in Firefox were gone, so now I have my doubts about the reliability and data integrity of XFS. My older server, which also runs openSUSE 10.2 (32-bit) but uses Ext3 as file system never had such issues and I had to reset it many times because it was hanging for some reason.

Am I right to assume that XFS compared to Ext3 does not do a very good job regarding data integrity? I know a little bit about file systems and I know that most file systems depend on the application to do the right job regarding the way it opens/locks/saves files, but in reality not all applications are written in a safe way to guarantee this.

Basically, my two question that I have are:

- Why did I lost bookmarks on a machine running XFS while on another one which runs the same OS version but uses Ext3 as file system, it never happened, no matter how many times I had to reset it.

- Are there any efforts currently made to increase the data integrity of XFS?

Regards

Hi,

short and rude answer: 'Search the archives and FAQs'.

Simply short answer: no and no.

Longer answer: XFS only cares about meta-data integrity, if unwritten extends exist in memory, you'll get these empty on the disk if you reset your box. You should consider using the 'Magic SysRq' hotkeys to emergency sync your disk in cases like these before you reset your box.

Ciao
Klaus

Mit freundlichen Grüssen / best regards

Klaus Strebel, Dipl.-Inform. (FH), mailto:[email protected]

/"\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \

sounds like you have several reliability problems ;-)

see also http://oss.sgi.com/projects/xfs/faq.html#nulls

this is essentially a loss of buffered data in the VM, outside the realm of what xfs can realistically protect. With ext3, you probably were losing your "latest" bookmarks as well, but were luckily(?) getting back whatever used to be on-disk.

On the other hand, there were some changes made to xfs to explicitly sync files on close, if they have been truncated, which should help this sort of problem. Depending on what's in OpenSuSE 10.2, that change may or may not be in your code...

-Eric

Take a look at the FAQ:
http://oss.sgi.com/projects/xfs/faq.html#wcache

Regarding the lost bookmarks, you might find an old backup in ~/.mozilla/firefox/<userprofile>/bookmarkbackups.

Regards
Stein

This is a firefox bug - I've seen it before (on my mother's machine).

It's due to firefox not doing the correct thing with IO on the bookmarks file.

As mentioned in another mail you can restore from a backup that firefox makes.

In a future release, firefox is going to be using sqlite for storing thes ethings, which will mean that these problems go away (pretty sure sqllite does all the right things)

Stewart Smith ([email protected])
http://www.flamingspork.com/

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

- From end-user's POV, this infamous XFS behavior is somewhat taken as XFS's inferiority compared to other filesystems. Even with "bad" applications (ex. firefox), this rarely happens on others, so regardless of what's on the FAQ, people logically concludes that the fault belongs to XFS anyway.

So, what is the correct way to do IO?
Is what firefox (and other bad apps) doing is so obvious(ly buggy), that it'll be acknowledged as a bug once reported? Or is it simply a mismatch between application expectation and XFS behavior, requiring a non-(obvious|generic) fix?

Although I'm not a filesystem developer, I'm pretty impressed with XFS and willing to file a report/patch to those "buggy" apps if the issue is explainable to other app developers.

- --
Taisuke Yamada <[email protected]>, http://rakugaki.org/
2268 E9A2 D4F9 014E F11D 1DF7 DCA3 83BC 78E5 CD3A

Message to my public address may not be handled in a timely manner. For a direct contact, please use my private address on my namecard. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+Mrq3KODvHjlzToRAu/vAKC8pky15WJwocHbWhbRx9f2H+c5aQCeIeYp ZJPcSeawAIbZN80GXJz+kYg=
=oAY3
-----END PGP SIGNATURE-----

side to do the right job but real world experience shows us that *a lot* of applications out there behave badly and cannot be trusted hence if something happens, XFS cannot "correct" the problem leaving you with headaches behind depending on how much data you lost/corrupted and the importance of it. IMHO, XFS *should* do some effort at assuring integrity to minimize the bad behavior of badly written applications out there. I know that XFS wasn't written for PC class hardware in the first place, but most people do not read enough to understand XFS and use it on their desktops/laptops because to be honest Linux doesn't really have a good file system, and XFS out of all available file systems, is the best in performance and scalability terms.

On the one hand you have the old Ext3 FS which doesn't perform very well in many areas but IMO is a lot safer to work on (doesn't loose data that easily compared to XFS - and I'm talking from experience here because I use both file systems and I lost much more on the XFS system than on the Ext3 one) and on the other hand you have this excellent XFS file system with its clean layout and awesome performance + fancy features like GRIO, extents, allocate on flush, real time volumes, etc *but* is not "safe" enough to work with if you have unreliable hardware and/or a lot of power outage issues - I've never lost data on Ext3 during a power outage but already lost 2 times data on XFS

Just my $0.02

You *always* use a UPS when you use XFS.
XFS does not prevent power outages [yet]...

Save them for a UPS. ;-)

Geir A. Myrestrand

Am Donnerstag 15 März 2007 schrieb clflush:

Hello,

as Eric wrote in this thread recent versions of XFS do an effort on avoiding these zeros in files:

"On the other hand, there were some changes made to xfs to explicitly sync files on close, if they have been truncated, which should help this sort of problem. Depending on what's in OpenSuSE 10.2, that change may or may not be in your code..."

Since 2.6.17.7 and enabled write barriers I didn't loose meta data consistency on my laptop anymore and I can tell you that it crashed a lot due to my experiments with what not (especially OSS radeon drivers and beryl;-). I also had some classical power outages. I usually do not put a battery into my laptop if not needed.

And with recent XFS I did not encounter any data losses at all. Might have been luck, but before after a crash or power outage Akkregator told me sometimes that the file with the newsfeed stuff was corrupted and a backup has been restored. I didn't see this dialog since a long time on my laptop.

That given I would like to have more safety built into the filesystem itself, but at least current ext3 is too ancient technology for me. Coming from the Amiga a filesystem with a hard maximum number of inodes just doesn't fit my expectations (although original Amiga FFS has lot of shortcomings too;-).

The real challenge is to implement safety without serious loss of performance. You have more data safety in ext3, but less performance, and more performance in XFS, but potential less data safety with badly written applications. Not almost every bit of additional performance in XFS comes from transferring responsibility of data safety to the application, but I believe there is a relationship between safety and performance.

Maybe wandering logs / a log structured approach as (partly) seen in Reiser 4 and NetApp's WAFL might be a good approach to get more data safety without (much) less performance. (Well in the NetApp FAS non volatile RAM plays an important role, too.)

Regards,

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

My laptop also supports write barriers, but I leave the battery in place in case there's a power outage; effectively it's operating as a UPS.

This might be slightly off-topic, but in choosing a SATA drive for a desktop machine, what features/standard-complaince should one look for in order to ensure that write barriers work? I know this involves flushing the drive cache, but is this support mandatory in any of the applicable standards?

Am Samstag 17 März 2007 schrieb Jason White:

Hello Jason!

I have no exact idea. I just now that dmesg usually tells you whether cache flushes are supported.

But shouldn't modern SATA drives support NCQ anyway? Since NCQ doesn't make any sense without the ability to flush the cache, I *think* any SATA drive with NCQ support should do. NCQ support would allow the block layer to offload the write barrier request ordering at least partly to the device firmware.

"ii. For devices which have queue depth greater than 1 but don't support ordered tags, block layer ensures that the requests preceding a barrier request finishes before issuing the barrier request. Also, it defers requests following the barrier until the barrier request is finished. Older SCSI controllers/drives and SATA drives fall in this category."

(Documentation/block/barrier.txt of Linux Kernel 2.6.20.4)

This also indicates that SATA drives should support NCQ.

Regards,

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7