Reiser File System Considered Harmful

Reprint from http://foner.www.media.mit.edu/people/foner/Sys/reiserfs-considered-harmful.txt


DO NOT USE REISERFS IF YOU VALUE DATA INTEGRITY.

Here's a piece of mail I wrote summarizing why not:

...and here's the documentation I refer to above. Note that the email addresses have been sanitized as a spam-prevention measure, and some of the messages have been omitted altogether if I wasn't sure they were public.

[LATE BREAKING NEWS: See also http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc for even more goodies on why you shouldn't ever be trusting your data to ReiserFS...]

- - - Begin forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -


==- |


==-- _ |

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -


==- |


==-- _ |

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - Separator between forwarded messages - - -

- - - End of forwarded messages - - -

=== An alternative view, by Keith Lofstrom

Data corruption during a power fail is an important issue. The dates in this collection of emails are all from 2001, and no version is mentioned for most of these problems. Reiserfs has gone through many versions and changes, and may or may not suffer from the same problems and bugs. A more up to date version of this discussion, and a summary of issues as they affect dirvish data files in a multiple-hard-linked rsync repository, would be helpful.

Personally, I would not run reiserfs as a random access main file system, for some of the reasons buried in that very long message. However, most issues do not apply to rsync generated data files the way dirvish uses it. The only files likely to be corrupted during a power failure would be part of a failed image, and thus inconsequential. The important thing is protecting file system pointers and metadata, and if I read the above correctly those are properly preserved through failures even for the early (and unnamed) versions of reiserfs that are being castigated here.

There is the worry that reiserfs will stuff a fragment of a new file onto the tail of a much older file, and thus corrupt an existing backup, but I would guess that all those old tails are long since filled up with little directory snippits. An expire may leave a lot of holes, though.

I use reiserfs-3 for my dirvish hard drives because it makes effective use of the disk space. Ext3 is horribly inefficient for that, most particularly because of the way it uses fixed-sized inode tables and wastes space for small files. With a rsync repository, the usual result is a target drive that fills up far too rapidly, maxing out at 70% usage when the inode table fills, or when all those tiny little directories and files that rsync chew up the available data space, one whole disk block to store a few dozen bytes. To compensate for that, many dirvish users must do frequent and deep expires, exposing the data structures on the disk to far more write activity than simple accumulative operation.

I typically back up around 100GB of data daily, and get around 150 non-expired images on a 250GB target drive before I retire it. I do not need to do expires. To mitigate the chances of disk failure (it has happened once) I do a rotating swap of 3 drives, so even if I lose the drive in the machine I still have recent backups on two other drives. This is affordable with reiserfs because I can get many more images on a drive. When I used ext3 for target drives, before I switched to reiserfs, I got a much less usage out of the target drives.

I also would not use reiserfs on really ancient hard drives. Disk drives have cache buffers, which need to be completely written out to disk, and the heads parked, immediately after a power failure. When newer drives sense a power failure, they use the energy stored in the turning spindle to power the drive long enough to write out the cache buffers and park the heads. Older drives do not do this, and partially written sectors can result, or sectors partly written in an unexpected order. Ext3 is more robust, so it is more likely to tolerate this kind of abuse. Reiser is more likely to corrupt data in these circumstances. So don't use reiserfs on old drives! I would guess that any drive with capacities of greater than 100GB will write out its entire cache properly before halting.

So it is a tradeoff, both ext3 and reiserfs have problems, and I find the problems with reiserfs less troublesome than ext3. Other dirvish users will disagree, and so the best thing for everyone is to report your empirical experience with file systems, used as dirvish banks, to the mailing list and to the wiki.

Ideally, someone will invent a file system that allocates disk space efficiently like reiserfs, without inode limitations and wasted space, and that also treats data more securely during power failures like ext3. I hope some of you are on the lookout for this.

Keith Lofstrom 2006 Sept 8

ReiserFSConsideredHarmful (last edited 2011-01-24 06:34:43 by KeithLofstrom)