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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
