On 08/02/2012 10:28 PM, Jan Schmidt wrote: > On Thu, August 02, 2012 at 15:46 (+0200), Arne Jansen wrote: >> On 02.08.2012 13:57, Liu Bo wrote: >>> Anyway, for now, our error flag has only been stored in memory, so what >>> about just keep it until we find a graceful way? >> >> Yeah, we need this patch to restore consistency. We can define a fixed >> area on disk (e.g. behind the superblock) where we can write the flag >> to without risking the superblock. > > At least we all agree that we need this patch, fine. > > We don't yet agree that we need a place to store a "please consider fsck" flag. > Can I please get one concrete example in which situation we > > a) do detect the user should really do a file system check AND > b) do not abort the transaction to clean the mess up? > > (An example on how we could fail transaction cleanup is also accepted). > Unfortunately I don't have such an example either. Since we always get COW on metadata, I believe that it's ok to just roll back on failure. > If such a situation doesn't exist, there's no need for this flag. The fact that > ext has such a flag doesn't convince me, probably because I know nothing about > ext. I can imagine that they can detect file system errors without the ability > to return to a potentially older consistent state. > This error flag is also used to indicate filesystem's error state for transaction cleanup, so keeping it in memory is reasonable. thanks, liubo > Thanks, > -Jan > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
