From: Chris Mason <chris.mason@oracle.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <nickpiggin@yahoo.com.au>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
"Theodore Ts'o" <tytso@mit.edu>,
stable@kernel.org
Subject: Re: [PATCH] rd: Mark ramdisk buffers heads dirty
Date: Wed, 17 Oct 2007 16:54:41 -0400 [thread overview]
Message-ID: <1192654481.15717.16.camel@think.oraclecorp.com> (raw)
In-Reply-To: <m17illeb8f.fsf@ebiederm.dsl.xmission.com>
On Wed, 2007-10-17 at 14:29 -0600, Eric W. Biederman wrote:
> Chris Mason <chris.mason@oracle.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Chris Mason <chris.mason@oracle.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <nickpiggin@yahoo.com.au>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Theodore Ts'o <tytso@mit.edu>,
stable@kernel.org
Subject: Re: [PATCH] rd: Mark ramdisk buffers heads dirty
Date: Wed, 17 Oct 2007 16:54:41 -0400 [thread overview]
Message-ID: <1192654481.15717.16.camel@think.oraclecorp.com> (raw)
In-Reply-To: <m17illeb8f.fsf@ebiederm.dsl.xmission.com>
On Wed, 2007-10-17 at 14:29 -0600, Eric W. Biederman wrote:
> Chris Mason <chris.mason@oracle.com> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-10-17 20:57 UTC|newest]
Thread overview: 155+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-15 8:28 [PATCH resend] ramdisk: fix zeroed ramdisk pages on memory pressure Christian Borntraeger
2007-10-15 8:28 ` Christian Borntraeger
2007-10-15 14:06 ` Nick Piggin
2007-10-15 14:06 ` Nick Piggin
2007-10-15 9:05 ` Christian Borntraeger
2007-10-15 9:05 ` Christian Borntraeger
2007-10-15 14:38 ` Nick Piggin
2007-10-15 14:38 ` Nick Piggin
2007-10-15 18:38 ` Eric W. Biederman
2007-10-15 18:38 ` Eric W. Biederman
2007-10-15 22:37 ` Eric W. Biederman
2007-10-15 22:37 ` Eric W. Biederman
2007-10-15 22:40 ` [PATCH] rd: Preserve the dirty bit in init_page_buffers() Eric W. Biederman
2007-10-15 22:40 ` Eric W. Biederman
2007-10-15 22:42 ` [PATCH] rd: Mark ramdisk buffers heads dirty Eric W. Biederman
2007-10-15 22:42 ` Eric W. Biederman
2007-10-16 7:56 ` Christian Borntraeger
2007-10-16 7:56 ` Christian Borntraeger
2007-10-16 8:05 ` rubenjr_22
2007-10-16 8:13 ` rubenjr_22
2007-10-16 9:22 ` Eric W. Biederman
2007-10-16 9:22 ` Eric W. Biederman
2007-10-17 16:14 ` Christian Borntraeger
2007-10-17 16:14 ` Christian Borntraeger
2007-10-17 17:57 ` Eric W. Biederman
2007-10-17 17:57 ` Eric W. Biederman
2007-10-17 19:14 ` Chris Mason
2007-10-17 19:14 ` Chris Mason
2007-10-17 20:29 ` Eric W. Biederman
2007-10-17 20:29 ` Eric W. Biederman
2007-10-17 20:54 ` Chris Mason [this message]
2007-10-17 20:54 ` Chris Mason
2007-10-17 21:30 ` Eric W. Biederman
2007-10-17 21:30 ` Eric W. Biederman
2007-10-17 22:58 ` Chris Mason
2007-10-17 22:58 ` Chris Mason
2007-10-17 23:28 ` Eric W. Biederman
2007-10-17 23:28 ` Eric W. Biederman
2007-10-18 0:03 ` Chris Mason
2007-10-18 0:03 ` Chris Mason
2007-10-18 3:27 ` Eric W. Biederman
2007-10-18 3:27 ` Eric W. Biederman
2007-10-18 3:59 ` [RFC][PATCH] block: Isolate the buffer cache in it's own mappings Eric W. Biederman
2007-10-18 3:59 ` Eric W. Biederman
2007-10-18 4:32 ` Andrew Morton
2007-10-18 4:32 ` Andrew Morton
2007-10-19 21:27 ` Eric W. Biederman
2007-10-19 21:27 ` Eric W. Biederman
2007-10-21 4:24 ` Nick Piggin
2007-10-21 4:24 ` Nick Piggin
2007-10-21 4:53 ` Eric W. Biederman
2007-10-21 4:53 ` Eric W. Biederman
2007-10-21 5:36 ` Nick Piggin
2007-10-21 5:36 ` Nick Piggin
2007-10-21 7:09 ` Eric W. Biederman
2007-10-21 7:09 ` Eric W. Biederman
2007-10-22 0:15 ` David Chinner
2007-10-22 0:15 ` David Chinner
2007-10-18 5:10 ` Nick Piggin
2007-10-18 5:10 ` Nick Piggin
2007-10-19 21:35 ` Eric W. Biederman
2007-10-19 21:35 ` Eric W. Biederman
2007-10-17 21:48 ` [PATCH] rd: Mark ramdisk buffers heads dirty Christian Borntraeger
2007-10-17 21:48 ` Christian Borntraeger
2007-10-17 22:22 ` Eric W. Biederman
2007-10-17 22:22 ` Eric W. Biederman
2007-10-18 9:26 ` Christian Borntraeger
2007-10-18 9:26 ` Christian Borntraeger
2007-10-19 22:46 ` Eric W. Biederman
2007-10-19 22:46 ` Eric W. Biederman
2007-10-19 22:51 ` [PATCH] rd: Use a private inode for backing storage Eric W. Biederman
2007-10-19 22:51 ` Eric W. Biederman
2007-10-21 4:28 ` Nick Piggin
2007-10-21 4:28 ` Nick Piggin
2007-10-21 5:10 ` Eric W. Biederman
2007-10-21 5:10 ` Eric W. Biederman
2007-10-21 5:24 ` Nick Piggin
2007-10-21 5:24 ` Nick Piggin
2007-10-21 6:48 ` Eric W. Biederman
2007-10-21 6:48 ` Eric W. Biederman
2007-10-21 7:28 ` Christian Borntraeger
2007-10-21 7:28 ` Christian Borntraeger
2007-10-21 8:23 ` Eric W. Biederman
2007-10-21 8:23 ` Eric W. Biederman
2007-10-21 9:56 ` Nick Piggin
2007-10-21 9:56 ` Nick Piggin
2007-10-21 18:39 ` Eric W. Biederman
2007-10-21 18:39 ` Eric W. Biederman
2007-10-22 1:56 ` Nick Piggin
2007-10-22 1:56 ` Nick Piggin
2007-10-22 13:11 ` Chris Mason
2007-10-22 13:11 ` Chris Mason
2007-10-21 9:39 ` Nick Piggin
2007-10-21 9:39 ` Nick Piggin
2007-10-21 17:56 ` Eric W. Biederman
2007-10-21 17:56 ` Eric W. Biederman
2007-10-22 0:29 ` Nick Piggin
2007-10-22 0:29 ` Nick Piggin
2007-10-16 8:19 ` [PATCH] rd: Mark ramdisk buffers heads dirty Nick Piggin
2007-10-16 8:19 ` Nick Piggin
2007-10-16 8:48 ` Christian Borntraeger
2007-10-16 8:48 ` Christian Borntraeger
2007-10-16 19:06 ` Eric W. Biederman
2007-10-16 19:06 ` Eric W. Biederman
2007-10-16 22:06 ` Nick Piggin
2007-10-16 22:06 ` Nick Piggin
2007-10-16 8:12 ` [PATCH] rd: Preserve the dirty bit in init_page_buffers() Nick Piggin
2007-10-16 8:12 ` Nick Piggin
2007-10-16 9:35 ` Eric W. Biederman
2007-10-16 9:35 ` Eric W. Biederman
2007-10-15 9:16 ` [PATCH resend] ramdisk: fix zeroed ramdisk pages on memory pressure Andrew Morton
2007-10-15 9:16 ` Andrew Morton
2007-10-15 15:23 ` Nick Piggin
2007-10-15 15:23 ` Nick Piggin
2007-10-16 3:14 ` Eric W. Biederman
2007-10-16 3:14 ` Eric W. Biederman
2007-10-16 6:45 ` Nick Piggin
2007-10-16 6:45 ` Nick Piggin
2007-10-16 4:57 ` Eric W. Biederman
2007-10-16 4:57 ` Eric W. Biederman
2007-10-16 8:08 ` Nick Piggin
2007-10-16 8:08 ` Nick Piggin
2007-10-16 7:47 ` [patch][rfc] rewrite ramdisk Nick Piggin
2007-10-16 7:52 ` Jan Engelhardt
2007-10-16 7:52 ` Jan Engelhardt
2007-10-16 8:07 ` Nick Piggin
2007-10-16 8:07 ` Nick Piggin
2007-10-16 8:17 ` Jan Engelhardt
2007-10-16 8:17 ` Jan Engelhardt
2007-10-16 8:26 ` Nick Piggin
2007-10-16 8:26 ` Nick Piggin
2007-10-16 8:53 ` Jan Engelhardt
2007-10-16 8:53 ` Jan Engelhardt
2007-10-16 9:08 ` Eric W. Biederman
2007-10-16 9:08 ` Eric W. Biederman
2007-10-16 21:28 ` Theodore Tso
2007-10-16 21:28 ` Theodore Tso
2007-10-16 22:08 ` Nick Piggin
2007-10-16 22:08 ` Nick Piggin
2007-10-16 23:48 ` Eric W. Biederman
2007-10-16 23:48 ` Eric W. Biederman
2007-10-17 0:28 ` Nick Piggin
2007-10-17 0:28 ` Nick Piggin
2007-10-17 1:13 ` Eric W. Biederman
2007-10-17 1:13 ` Eric W. Biederman
2007-10-17 1:47 ` Nick Piggin
2007-10-17 1:47 ` Nick Piggin
2007-10-17 10:30 ` Eric W. Biederman
2007-10-17 10:30 ` Eric W. Biederman
2007-10-17 12:49 ` Nick Piggin
2007-10-17 12:49 ` Nick Piggin
2007-10-17 18:45 ` Eric W. Biederman
2007-10-17 18:45 ` Eric W. Biederman
2007-10-18 1:06 ` Nick Piggin
2007-10-18 1:06 ` Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1192654481.15717.16.camel@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=schwidefsky@de.ibm.com \
--cc=stable@kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.