[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: WAPBL and backwards compatibility
On Fri, Aug 01, 2008 at 11:48:13AM +0200, Martin Husemann wrote:
> On Fri, Aug 01, 2008 at 11:03:39AM +0200, Alan Barrett wrote:
> > I think that we should do option 2 in the short term, option 4 if
> > anybody has a good design with code, and a bit of option 1 for good
> > measure.
> Yes, exactly.  will cause problems on some archs, so we better not do it,
> as Chris pointed out.  is free, so lets do it.
 can't cause any problems on archs that are outside our ability to
address, since we've fixed any such issues before, for FFS1/FFS2.
 should of course be done, since it's 'free' (code work, but no
space overhead or flag-days) - but only handles the second half of the
My concerns were based on an earlier explanation by Martin, but Simon's
comments seem to clarify the risks involved a bit more.
My understanding is that the risk is that a WAPBL unclean shutdown
followed by an un-WAPBL-aware fsck is that fsck will act on the
filesystem since the last log-flush. Since data isn't logged, but
metadata is, data operations will have run ahead of meta-data. I can't
remember off the top of my head all the details of which choices fsck
will make, but obvious examples are files that are growing will be
longer than the inode claims, and files that are deleted won't have been
deleted yet. The degree of trouble will depend on how long it is between
None of that sounds like deadly corruption (which was the impression I
had previously) - just 'a bit worse than a normal fsck'. If that's
accurate, then protecting against replaying a stale log is more
In addition to checking whether the FS is marked clean, could we also
check fs_time against any timestamp on the log? I'm thinking of the case
where the FS is fcsk'd/mounted by a non-WAPBL-aware kernel, worked with,
and shutdown uncleanly - followed by a boot with a WAPBL-aware system.
In that case, the log is _really_ old.
Main Index |
Thread Index |