On Wed, 2007-10-17 at 14:29 -0600, Eric W. Biederman wrote: > Chris Mason <[EMAIL PROTECTED]> writes: > > > In this case, the commit block isn't allowed to be dirty before reiserfs > > decides it is safe to write it. The journal code expects it is the only > > spot in the kernel setting buffer heads dirty, and it only does so after > > the rest of the log blocks are safely on disk. > > Ok. So the journal code here fundamentally depends on being able to > control the order of the writes, and something else being able to set > the buffer head dirty messes up that control. >
Right. > >> At the same time I increasingly don't think we should allow user space > >> to dirty or update our filesystem metadata buffer heads. That seems > >> like asking for trouble. > >> > > > > Demanding trouble ;) > > Looks like it. There are even comments in jbd about the same class > of problems. Apparently dump and tune2fs on mounted filesystems have > triggered some of these issues. The practical question is any of this > trouble worth handling. > > Thinking about it. I don't believe anyone has ever intentionally built > a filesystem tool that depends on being able to modify a file systems > metadata buffer heads while the filesystem is running, and doing that > would seem to be fragile as it would require a lot of cooperation > between the tool and the filesystem about how the filesystem uses and > implement things. > That's right. For example, ext2 is doing directories in the page cache of the directory inode, so there's a cache alias between the block device page cache and the directory inode page cache. > Now I guess I need to see how difficult a patch would be to give > filesystems magic inodes to keep their metadata buffer heads in. Not hard, the block device inode is already a magic inode for metadata buffer heads. You could just make another one attached to the bdev. But, I don't think I fully understand the problem you're trying to solve? -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/