XFS In Dapper [previously posted to ubuntu-users]

[Owen Townend]

On 3/6/08, Daniel Pittman <daniel at rimspace.net> wrote:
>
> Michael Hipp <Michael at Hipp.com> 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:
> > http://www.debian-administration.org/articles/388#comment_40
> >     (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.)
>
>
> > http://www.tummy.com/journals/entries/jafo_20041226_015752
>
>
> 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
> ubuntu-server at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam
>

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. --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20080307/14d2af4b/attachment.html>