Al Boldi wrote:
Greetings!
data=ordered mode has proven reliable over the years, and it does this by
ordering filedata flushes before metadata flushes. But this sometimes
causes contention in the order of a 10x slowdown for certain apps, either
due to the misuse of fsync or due to inherent b
Latchesar Ionkov wrote:
Sample ramfs file server that uses the in-kernel 9P file server support.
This code is for reference only.
Reference code generally goes in Documentation/
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message
From: Chris Snook <[EMAIL PROTECTED]>
Remove printk from J_ASSERT to preserve registers during BUG.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/linux/jbd2.h 2007-08-13 03:14:13.0
-0400
+++ linux-2.6.23-rc3-patch/include/linux/jbd2.h 2
From: Chris Snook <[EMAIL PROTECTED]>
Remove printk from J_ASSERT to preserve registers during BUG.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/linux/jbd.h 2007-07-08 19:32:17.0
-0400
+++ linux-2.6.23-rc3-patch/include/linux/jbd.h 2
The printk() in J_ASSERT clobbers registers, making it more difficult to
determine what caused the assertion failure. We can deduce the assertion itself
from the line number in the BUG() message, so let's just use that, and keep our
registers intact for better debugging. While the hood is up,
Andrew Morton wrote:
On Fri, 17 Aug 2007 01:54:18 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
The J_ASSERT() macro in jbd and jbd2 calls printk() prior to BUG(). While this
makes it more convenient to read the assertion failure, it also clobbers
registers, which can sometimes make deb
From: Chris Snook <[EMAIL PROTECTED]>
Don't printk before BUG in J_ASSERT unless CONFIG_JBD2_DEBUG is set.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/linux/jbd2.h 2007-08-13 03:14:13.0
-0400
+++ linux-2.6.23-rc3-patch/include/lin
From: Chris Snook <[EMAIL PROTECTED]>
Don't printk before BUG in J_ASSERT unless CONFIG_JBD_DEBUG is set.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/linux/jbd.h 2007-07-08 19:32:17.0
-0400
+++ linux-2.6.23-rc3-patch/include/lin
The J_ASSERT() macro in jbd and jbd2 calls printk() prior to BUG(). While this
makes it more convenient to read the assertion failure, it also clobbers
registers, which can sometimes make debugging harder, which is clearly not the
intended purpose. I recently banged my head on this myself.
T
Bryan Henderson wrote:
The directory is quite visible with a standard 'ls -a'. Instead,
they simply mark it as a separate volume/filesystem: i.e. the fsid
differs when you call stat(). The whole thing ends up acting rather like
our bind mounts.
Hmm. So it breaks user space quite a bit. By bre
Jack Stone wrote:
Chris Snook wrote:
Jack Stone wrote:
H. Peter Anvin wrote:
Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be t
Jack Stone wrote:
Chris Snook wrote:
Jack Stone wrote:
The idea was that if you did an ls you would get the latest version of
the file without the :revision_num. The only visible version would be
the latest version, i.e. the current system would not change. The idea
was that it would only show
Jack Stone wrote:
H. Peter Anvin wrote:
Chris Snook wrote:
I pointed out NetApp's .snapshot directories because that's a method
that uses legal path character, but doesn't break anything. With this
method, userspace tools will have to be taught that : is suddenly a
special cha
Jack Stone wrote:
Chris Snook wrote:
But what you're talking about *will* break userspace. If I do an ls in
a directory, and get pages upon pages of versions of just one file,
that's broken. If I tar up a directory and get a tarball that's
hundreds of times larger than it sh
Jack Stone wrote:
Chris Snook wrote:
The underlying internal implementation of something like this wouldn't
be all that hard on many filesystems, but it's the interface that's the
problem. The ':' character is a perfectly legal filename character, so
doing it that way
Jack Stone wrote:
I hope I got the CC list right. Apologies to anyone in didn't include
and anyone I shouldn't have included.
The basic idea is to include an idea from VMS that seems to be quite
useful: version numbers for files.
The idea is that whenever you modify a file the system saves it t
16 matches
Mail list logo
