<div>On 3/6/08, Daniel Pittman <<a href="mailto:daniel@rimspace.net">daniel@rimspace.net</a>> wrote:<blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex"> Michael Hipp <<a href="mailto:Michael@Hipp.com">Michael@Hipp.com</a>> writes: > Oliver Brakmann wrote: >> On Wed, 2008-03-05 17:04, David Kempe wrote... > >>> Importantly, you can have data-loss on XFS if you lose power suddenly, >>> perhaps more so than ext3. When files get corrupted on XFS, I have >>> noticed they go to zero size >> >> I believe I read somewhere that that has been fixed some time ago. > > Oliver, could you perchance find a reference for that? Dapper really > isn't that old. The change was in 2.6.24, so will be in Hardy, but is not present in any file system before that. There were some data corruption bugs around 2.6.17, none of which were ever in an Ubuntu release that I am aware of, and which have since been fixed; these are unlikely to be what the posters here are describing.[1] > Not disagreeing. I'd *like* to use XFS, I just feel burned by it. An > indicator that this issue has been solidly addressed would be great > news. It should be more or less as solid as writeback ext3 now, but less safe than data journaled ext3. > Some things to read: > <a href="http://www.debian-administration.org/articles/388#comment_40">http://www.debian-administration.org/articles/388#comment_40</a> > (read all comments to the end) This comment, and the few subsequent, are a misunderstanding of how things work. The problem illustrated is not that "enterprise applications do their own data recovery." The problem is that POSIX file semantics make some things safe and some things dangerous regarding your files. The applications that see NULL content would probably be corrupt on disk, since they have changed their size and (potentially) appended random data to the end of their content. The sad part is that most application developers don't really understand POSIX I/O semantics and, so, many popular applications are vulnerable to this. (hint for those at home: write your content to a new file and rename it over the existing one; this is atomic, assuring you that the new or the old file is there, nothing in between. for bonus points include some recovery to determine if the new version is complete and coherent, then offer to complete the task.) > <a href="http://www.tummy.com/journals/entries/jafo_20041226_015752">http://www.tummy.com/journals/entries/jafo_20041226_015752</a> For a user who claims to care about data integrity this poster seems to have little actual clue: JFS is an exciting choice, at best, and reiserfs... Well, hey, the point someone starts talking about using reiserfs and data integrity being important to them you can more or less know they don't really understand how data integrity is achieved. reiserfs (3) has significant issues, many of which are performance or data integrity related, and is close to impossible to recover if /anything/ goes wrong.[2] Regards, Daniel Footnotes: [1] Their symptoms were completely different, much nastier, and fairly identifiable. Zero length or null-filled files were not among them. [2] ...or you happen to store anything that looks like a reiserfs filesystem inside them when you run the fsck tools.[3] [3] This is highly amusing to me as I recall the excitement when the developers announced a library version of reiserfs intended as a "compound document" format for applications to use, delivering the same performance as the file system they were stored in... -- ubuntu-server mailing list <a href="mailto:ubuntu-server@lists.ubuntu.com">ubuntu-server@lists.ubuntu.com</a> <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-server">https://lists.ubuntu.com/mailman/listinfo/ubuntu-server</a> More info: <a href="https://wiki.ubuntu.com/ServerTeam">https://wiki.ubuntu.com/ServerTeam</a> </blockquote></div> Hey, Thought I'd share my experiences with reiserfs... I'm using reiserfs on my mythtv box with a 4x400GB software raid5 array (~1.2TB usable) and it has been ok, but also unstressed so I won't go as far as vouching for it in a production environment. It's strength seems to lie in large numbers of small files rather than the large audio/video you're using. On the recovery side though, I was fiddling with the underlying lvm & md and managed to bork the system. I rebuilt the whole thing with the exact same parameters as I used originally and ran the reiserfs recovery tool to find it pulling files out of my (reiserfs formatted) VM images as well as the files actually in the fs. I ended up getting back _most_ of my data and had backups of the vms, so it wasn't a complete loss. I think the tried and tested 'just works' of ext3 would probably be a better choice in a potential recovery situation. My new place has brown outs during almost every storm and I've yet to invest in a UPS, the system has so far come back up without issue. cheers, Owen. -- If it aint broke, fix it 'till it is. --