Gentoo Archives: gentoo-user

From: William Kenworthy <billk@×××××××××.au>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Good file system that recovers from a power failure.
Date: Sun, 02 Jan 2011 02:33:45
Message-Id: 1293935502.20855.23.camel@rattus
In Reply to: Re: [gentoo-user] Good file system that recovers from a power failure. by Dale
1 On Fri, 2010-12-31 at 19:12 -0600, Dale wrote:
2 > Alan McKinnon wrote:
3 > > Apparently, though unproven, at 00:27 on Saturday 01 January 2011, Dale did
4 > > opine thusly:
5 > >
6 > >
7 > >
8 > >>> It's my opinion that reiser is in security-fix-only mode from whoever is
9 > >>> maintaining it. If everything else around it stays the same, the fs will
10 > >>> obviously continue working just as it always did. But the surrounding
11 > >>> system is not stable, it changes rapidly, especially in kernel space, so
12 > >>> the odds are stacked against reiser for bitrot. For all these reasons, I
13 > >>> regretfully switched my own systems over to ext4 some time ago. Rieser
14 > >>> was a good fs whose time has come and gone and I no longer had warm and
15 > >>> fuzzies about the future with it.
16 > >>>
17 > >> I'm not sure I EVER saw a update to reiserfs. I was hoping it was just
18 > >> that good. lol
19 > >>
20 > >> This is also the reason I was considering moving to ext4 or something.
21 > >> How has ext4 been treating you since the switch? I also assume you have
22 > >> UPSs as well?
23 > >>
24 > > It's still early days, but ext4 has been good here on all machines. I don't
25 > > have a UPS (couldn't be bothered really...) so the UPS is the device's
26 > > battery. Which means me doing something really stupid and locking the machine
27 > > up is the most common reason for hard reboots. It survived every time so far.
28 > >
29 > >
30 >
31 > That sounds good. Your situation is not a theory but real and in
32 > practice. We all know what happens to theories. :-(
33 >
34 > Dale
35 >
36 > :-) :-)
37 >
38
39 As someone who suffered from a rare, but fatal bug in some kernel
40 updates to reiserfs3 which were only fixed in a recent versions, I can
41 say yes, its still being actively maintained.
42
43 But, I am thinking its time to move on - in particular something that
44 can fsck online (my mythtv and backup archives on reiserfs have to be
45 done offline and its takes hours to do terrabytes!) and still be robust.
46
47 I use "dirvish" for backups which creates a LOT of hardlinks which can
48 be very hard on a file system. ext2 typically lasts only a few cycles,
49 while ext3 is only a little better even with full journalling. Coupled
50 to the fact neither is very good with power cuts and they are a worst
51 case choice for data security :)
52
53 Reiserfs3 by contrast is very very good, with only a few instances of
54 problems over many years (since beore 3 was even in the kernel) - none
55 of which have lost critical data or file systems (ext2/3 devs, are you
56 listening :) Even the "slowpath" bug I ran into just required a kernel
57 downgrade and an fsck until later kernel versions fixed the bug.
58
59 I am now trying btrfs and am very impressed. On line fsck is wonderful
60 and I have had one instace of corruption due to a flakey hard disk - the
61 partition is on lvm so I moved it to another disk in the array and its
62 been solid since - didnt lose it or any any data. The dirvish backups
63 are fast enough (impression only, no timings) but large scale deleted
64 (60Gb copies of laptops etc) are much slower than reiserfs. My only
65 "glitch" has been dirvish/btrfs inability to deal with a ".gvfs" file in
66 some home directories - it has some wierd permissions but an exclusion
67 from the backup regime bypasses it. reiserfs doesn't have a problem
68 with it.
69
70 So, for me at least, btrfs is looking like the way forward. Its in
71 "testing" at the moment, but I am ready to move whole systems over to
72 it.
73
74 BillK
75
76
77
78 --
79 William Kenworthy <billk@×××××××××.au>
80 Home in Perth!

Replies

Subject Author
Re: [gentoo-user] Good file system that recovers from a power failure. Walter Dnes <waltdnes@××××××××.org>