Date: Tue, 27 Dec 2011 23:35:07 -0759 From: David Thiel <lx@redundancy.redundancy.org> To: Scott Long <scottl@samsco.org> Cc: freebsd-current@freebsd.org, d@delphij.net Subject: Re: SU+J systems do not fsck themselves Message-ID: <20111228073442.GM45484@redundancy.redundancy.org> In-Reply-To: <6F3ACDEE-B656-46D0-AB11-FF1B23E70A27@samsco.org> References: <20111227215330.GI45484@redundancy.redundancy.org> <CAGMYy3t3Rv006qvBCHr4kdbM86andkr5mRkvaGYw5CETO1XHkg@mail.gmail.com> <20111227223638.GK45484@redundancy.redundancy.org> <4EFA4B4E.201@delphij.net> <20111228051404.GL45484@redundancy.redundancy.org> <6F3ACDEE-B656-46D0-AB11-FF1B23E70A27@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 27, 2011 at 11:54:20PM -0700, Scott Long wrote: > The first run of fsck, using the journal, gives results that I would > expect. The second run seems to imply that the fixes made on the > first run didn't actually get written to disk. This is definitely an > oddity. I see that you're using geli, maybe there's some strange > side-effect there. No idea. Report as a bug, this is definitely > undesired behavior. Not impossible, but I was seeing similar issues on two non-geli systems as well, i.e. tons of errors fixed when doing a single-user non-journalled fsck, but journalled fsck not fixing stuff. I'll try to replicate on a test machine, as I already lost data on the last (non-geli) machine this happened to. > For the love that is all good and holy, don't ever run fsck on a live > filesystem. It's going to report these kinds of problems! It's > normal; filesystem metadata updates stay cached in memory, and fsck > bypasses that cache. Ok. I expected fsck would be softupdate-aware in that way, but I understand it not doing so. > > - SU+J and fsck do not work correctly together to fix corruption on > > boot, i.e. bgfsck isn't getting run when it should > > The point of SUJ is to eliminate the need for bgfsck. Effectively, > they are exclusive ideas. This is surprising to me. It is my impression that under Linux at least, ext3fs is checked against the journal, and gets a full e2fsck if it finds it's still dirty. Additionally, there's a periodic fsck after 180 days continuous runtime or x number of mounts (see tune2fs -i and -c). Is SU+J somehow implemented in such a way that this is unnecessary? What does it do that the ext3fs people have missed?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111228073442.GM45484>