| Randy Dunlap | [PATCH 4/4] docbook: fix filesystems content
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix filesystems docbook warnings.
Warning(linux-2.6.23-git8//fs/debugfs/file.c:241): No description found for parameter 'name'
Warning(linux-2.6.23-git8//fs/debugfs/file.c:241): No description found for parameter 'mode'
Warning(linux-2.6.23-git8//fs/debugfs/file.c:241): No description found for parameter 'parent'
Warning(linux-2.6.23-git8//fs/debugfs/file.c:241): No description found for parameter 'value'
Warning(linux-2.6.23-git8//include/linux/j...
| Oct 15, 8:30 pm 2007 |
| Chris Mason | More Large blocksize benchmarks
Hello everyone,
I'm stealing the cc list and reviving and old thread because I've
finally got some numbers to go along with the Btrfs variable blocksize
feature. The basic idea is to create a read/write interface to
map a range of bytes on the address space, and use it in Btrfs for all
metadata operations (file operations have always been extent based).
So, instead of casting buffer_head->b_data to some structure, I read and
write at offsets in a struct extent_buffer. The extent buffer is ve...
| Oct 15, 8:22 pm 2007 |
| David Chinner | Re: More Large blocksize benchmarks
Apples to oranges, Chris ;)
btrfs linearises writes due to it's COW behaviour and this is trades
off read speed. i.e. we take more seeks to read data so we can keep
the write speed high. By using large blocks, you're reducing the
number of seeks needed to find anything, and hence the read speed
will increase. Write speed will be pretty much unchanged because
btrfs does linear writes no matter the block size.
XFS doesn't linearise writes and optimises it's layout for a large
number of disks and...
| Oct 15, 10:36 pm 2007 |
| Christoph Lameter | Re: More Large blocksize benchmarks
Dave's tests were done with an early large blocksize patchset that had
issues with readahead. More recent versions have the fixes by Fengguang
that address the issue.
-
| Oct 15, 8:44 pm 2007 |
| J. Bruce Fields | [GIT] locks.c updates for 2.6.24
You can pull the following file-locking changes from:
git://linux-nfs.org/~bfields/linux.git locks
Cleanup, minor bugfixes and some documentation patches. They've been in
-mm for a while.
(By the way, I've also started some very primitive lease and flock
tests, available from:
git://linux-nfs.org/~bfields/lock-tests.git
and I'm mainly depending on those and connectathon locking tests for
now.)
--b.
J. Bruce Fields (7):
locks: reverse order of posix_locks_conflict() argumen...
| Oct 15, 6:53 pm 2007 |
| David Chinner | Re: XFS regression?
Because the inode has been modified, and instead of sprinkling
mark_inode_dirty_sync() all over the code, we can do it in a single
spot that catches all inode modifications. We don't have to think about
Sure, but there's plenty of other transactions that don't have such
a convenient hook.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
| Oct 15, 7:57 am 2007 |
| Christoph Hellwig | Re: 2.6.23-mm1: BUG in reiserfs_delete_xattrs
The delete path is a similar case as the one Dave fixed, also cause by
a NULL vfsmount passed to dentry_open, but through a different code-path.
Untested fix for this problem below:
Index: linux-2.6.23-rc8/fs/reiserfs/xattr.c
===================================================================
--- linux-2.6.23-rc8.orig/fs/reiserfs/xattr.c 2007-09-30 14:13:46.000000000 +0200
+++ linux-2.6.23-rc8/fs/reiserfs/xattr.c 2007-09-30 14:18:30.000000000 +0200
@@ -207,9 +207,8 @@ static struct dentry *get_...
| Oct 15, 4:40 am 2007 |
| Laurent Riffard |
| Oct 15, 3:51 pm 2007 |
| Jeff Mahoney | Re: 2.6.23-mm1: BUG in reiserfs_delete_xattrs
Here's a patch I worked up the other night that kills off struct file
completely from the xattr code. I've tested it locally.
After several posts and bug reports regarding interaction with the NULL
nameidata, here's a patch to clean up the mess with struct file in the
reiserfs xattr code.
As observed in several of the posts, there's really no need for struct file
to exist in the xattr code. It was really only passed around due to the
f_op->readdir() and a_ops->{prepare,commit}_wri...
| Oct 15, 2:31 pm 2007 |
| Laurent Riffard | Re: 2.6.23-mm1: BUG in reiserfs_delete_xattrs
Sorry Jeff, your patch does not apply on 2.6.23-mm1. The 'struct file'
removal from reiserfs_xattr_ function is already in -mm
(make-reiserfs-stop-using-struct-file-for-internal.patch).
The Dave's patch I was refering to is this one:
==== BEGIN =====
The bug is caused by reiserfs creating a special 'struct file' with a
NULL vfsmount.
/* Opens a file pointer to the attribute associated with inode */
static struct file *open_xa_file(const struct inode *inode, const char
*name,
...
| Oct 15, 4:06 pm 2007 |
| Jeff Mahoney | Re: 2.6.23-mm1: BUG in reiserfs_delete_xattrs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'd guess not. This patch was actually against mainline. I should've
specified. I can work up one against -mm later today if it's needed.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHE8wyLPWxlyuTD7IRAiJrAJ4nC6gwH1cFjWx6BI04O5fDIRftmACcD2wb
whyXThHlIBK2phnZ6Pf8Pb8=
=Kx6k
-----END PGP SIGNATURE-----
-
| Oct 15, 4:23 pm 2007 |
| Bryan Henderson | Re: Correct behavior on O_DIRECT sparse file writes
That makes sense, but how do you explain the committing of the size change
without O_SYNC? That seems wrong to me.
This does need to be documented carefully, because a person could easily
believe, even subconsciously, that O_DIRECT makes the entire file write
direct, and sloppy documentation might actually use words to that effect.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
| Oct 15, 12:53 pm 2007 |
| Chuck Lever |
| Oct 15, 11:36 am 2007 |
| Pekka Enberg | Re: msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userl...
Hi,
I wonder whether _not setting_ BDI_CAP_NO_WRITEBACK implies that
->writepage() will never return AOP_WRITEPAGE_ACTIVATE for
!wbc->for_reclaim case which would explain why we haven't hit this bug
before. Hugh, Andrew?
And btw, I think we need to fix ecryptfs too.
Pekka
-
| Oct 15, 7:47 am 2007 |
