On Monday 01 December 2008 18:38, Jim Avera wrote: > I was randomly reading > http://tux3.org/pipermail/tux3/2008-September/000186.html > for pleasure and noticed a possible latent corruption bug in Daniel > Phillips's post of the atom-refcount-update procedure (below). > > If an i/o error occurs while reading the block containing the upper-16 > bits of refcount, the procedure nevertheless updates the low-16 bits of > refcount on disk, and then returns an EIO error. The fix probably > requires bread-ing both blocks into separate buffers before modifying > either (only one block if the upper-16 remain zero, of course). > > I don't know anything about tux3, so perhaps some higher-level mechanism > un-does the incorrect update of the low-16 refcount after the EIO is > returned. But if not, a flaky disk (or network link to a disk) might > result in the refcount being silently reduced by 65535.
Exactly. If we get EIO on a buffer update we will not commit the transaction containing the atom update at all, and put the volume into read-only mode just like Ext3 does. That is our first line of defense anyway, we will refine that as we go. Ultimately, we want to be able to "power through" a nasty like this and keep going, picking up the pieces as we can. If that means walking all the inode table blocks in the system to recount the xattr atoms, then so be it. And we can run for quite some time without tracking atom counts at all, which is nice for this particular case. We would map the refcount somewhere else (to a different physical device hopefully) and continue, counting only the _new_ reference counts, while gathering up the pre-existing ones from the atom table. (To be precise, we track only new updates to the inodes we have already scanned during this recovery.) > For reference, here is Daniel's code from the post (without endien-ness > stuff): Thanks for the sharp eyes :-) It's not actually a bug for the reason above, but I did not explained that before I think , so until I did it was a bug. Daniel _______________________________________________ Tux3 mailing list [email protected] http://tux3.org/cgi-bin/mailman/listinfo/tux3
