vfs pile 1
Al Viro
maintainer Contains: d_op series on top of Nick's pile, a few other patches
from various folks. More tomorrow; there's a huge pending pile here.
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ for-linus
Note: d_set_d_op() is still there, but most of the callers are gone. FWIW, there are only 3 non-trivial bunches:
* procfs - as expected, we have shitloads of ->d_op there
* autofs4 - tomorrow will be fun; automount series needs to be
dealt with to sort that out
* ceph - I'd rather deal with that on top of ceph tree.
Shortlog:
Al Viro (31):
per-superblock default ->d_op
fix isofs d_op handling
switch fat to ->s_d_op, close exportfs races there switch jfs to ->s_d_op, close exportfs races
pohmelfs: double-free and leak
switch fuse
switch sysv
minixfs: kill dead code
switch hfs
switch hfsplus
switch adfs
switch nfs to ->s_d_op
switch cifs
switch gfs2, close races
switch ocfs2, close races
switch btrfs, close races
switch cgroup
switch hpfs
convert smbfs
switch coda
take coda-private headers out of include/linux switch configfs
switch affs
switch hostfs
pass default dentry_operations to mount_pseudo() switch 9p
switch ncpfs
move internal-only parts of ncpfs headers to fs/ncpfs switch afs
sanitize ecryptfs ->mount()
fix signedness mess in rw_verify_area() on 64bit architectures
Jeff Layton (1):
vfs: pass struct file to do_truncate on O_TRUNC opens (try #2)
Josef Bacik (7):
fs: add hole punching to fallocate
XFS: handle hole punching via fallocate properly
Ocfs2: handle hole punching via fallocate properly
Ext4: fail if we try to use hole punch
Btrfs: fail if we try to use hole punch
Gfs2: fail if we try to use hole punch
fs: add documentation on fallocate hole punching
Randy Dunlap (2):
fs: fix kernel-doc for dcache::d_validate
fs: fix kernel-doc for dcache::prepend_path
Diffstat:
Documentation/filesystems/porting | 9 ++
Documentation/magic-number.txt | 2 +-
arch/ia64/kernel/perfmon.c | 6 +-
drivers/mtd/mtdchar.c | 2 +-
drivers/staging/pohmelfs/net.c | 2 +-
drivers/staging/smbfs/dir.c | 13 ---
drivers/staging/smbfs/inode.c | 4 +
drivers/staging/smbfs/proto.h | 2 +
fs/9p/v9fs_vfs.h | 1 -
fs/9p/vfs_dentry.c | 2 +-
fs/9p/vfs_inode.c | 5 -
fs/9p/vfs_super.c | 8 +-
fs/adfs/dir.c | 1 -
fs/adfs/super.c | 4 +-
fs/affs/affs.h | 1 +
fs/affs/namei.c | 3 +-
fs/affs/super.c | 6 +-
fs/afs/dir.c | 4 +-
fs/afs/internal.h | 1 +
fs/afs/super.c | 1 +
fs/anon_inodes.c | 21 ++--
fs/block_dev.c | 2 +-
fs/btrfs/export.c | 12 +--
fs/btrfs/inode.c | 6 +-
fs/btrfs/super.c | 1 +
fs/cifs/cifsfs.c | 6 +
fs/cifs/dir.c | 25 +-----
fs/cifs/inode.c | 8 --
fs/cifs/link.c | 4 -
fs/cifs/readdir.c | 5 -
fs/coda/cache.c | 5 +-
fs/coda/cnode.c | 3 +-
{include/linux => fs/coda}/coda_cache.h | 0
{include/linux => fs/coda}/coda_fs_i.h | 0
fs/coda/coda_linux.c | 3 +-
{include/linux => fs/coda}/coda_linux.h | 4 +-
fs/coda/dir.c | 9 +-
fs/coda/file.c | 3 +-
fs/coda/inode.c | 6 +-
fs/coda/pioctl.c | 4 +-
fs/coda/psdev.c | 4 +-
fs/coda/symlink.c | 4 +-
fs/coda/upcall.c | 5 +-
fs/configfs/configfs_internal.h | 1 +
fs/configfs/dir.c | 6 +-
fs/configfs/mount.c | 1 +
fs/dcache.c | 9 +-
fs/ecryptfs/inode.c | 1 -
fs/ecryptfs/main.c | 155 ++++++++++++++-----------------
fs/ext4/extents.c | 4 +
fs/fat/fat.h | 3 +-
fs/fat/inode.c | 13 +--
fs/fat/namei_msdos.c | 27 ++----
fs/fat/namei_vfat.c | 27 ++----
fs/fuse/dir.c | 1 -
fs/fuse/inode.c | 10 +-
fs/gfs2/export.c | 13 +--
fs/gfs2/ops_fstype.c | 2 +-
fs/gfs2/ops_inode.c | 6 +-
fs/hfs/dir.c | 2 -
fs/hfs/super.c | 3 +-
fs/hfsplus/dir.c | 1 -
fs/hfsplus/super.c | 2 +-
fs/hostfs/hostfs_kern.c | 2 +-
fs/hpfs/dentry.c | 7 +-
fs/hpfs/dir.c | 1 -
fs/hpfs/hpfs_fn.h | 2 +-
fs/hpfs/super.c | 2 +-
fs/isofs/inode.c | 13 ++-
fs/isofs/namei.c | 2 -
fs/jfs/namei.c | 10 +--
fs/jfs/super.c | 6 +-
fs/libfs.c | 4 +-
fs/minix/namei.c | 2 -
fs/namei.c | 7 +-
fs/ncpfs/dir.c | 19 +---
fs/ncpfs/file.c | 3 +-
fs/ncpfs/inode.c | 6 +-
fs/ncpfs/ioctl.c | 4 +-
fs/ncpfs/mmap.c | 4 +-
fs/ncpfs/ncp_fs.h | 98 +++++++++++++++++++
{include/linux => fs/ncpfs}/ncp_fs_i.h | 0
{include/linux => fs/ncpfs}/ncp_fs_sb.h | 24 ++++-
fs/ncpfs/ncplib_kernel.c | 2 +-
fs/ncpfs/ncplib_kernel.h | 2 -
fs/ncpfs/ncpsign_kernel.c | 1 +
fs/ncpfs/ncpsign_kernel.h | 2 -
fs/ncpfs/sock.c | 2 +-
fs/ncpfs/symlink.c | 4 +-
fs/nfs/dir.c | 4 -
fs/nfs/getroot.c | 6 -
fs/nfs/super.c | 1 +
fs/ocfs2/export.c | 6 +-
fs/ocfs2/file.c | 8 +-
fs/ocfs2/namei.c | 5 -
fs/ocfs2/super.c | 1 +
fs/open.c | 7 +-
fs/pipe.c | 4 +-
fs/read_write.c | 27 ++---
fs/sysv/namei.c | 1 -
fs/sysv/super.c | 8 +-
fs/xfs/linux-2.6/xfs_iops.c | 7 +-
include/linux/falloc.h | 1 +
include/linux/fs.h | 5 +-
include/linux/ncp_fs.h | 100 --------------------
include/linux/ncp_mount.h | 22 -----
kernel/cgroup.c | 30 ++-----
net/socket.c | 30 +++---
108 files changed, 424 insertions(+), 582 deletions(-)Hi Al,
Quoted 5 lines · On Thu, 13 Jan 2011 05:35:54 +0000 Al Viro <[email protected]> wrote:
Contains:
d_opseries on top of Nick's pile, a few other patches
from various folks. More tomorrow; there's a huge pending pile here.
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/for-linus
None of this has been in linux-next. Some of it seems to date back into early December and even November ...
Merging it into today's linux-next produces conflicts against the ecryptfs and cleancache trees.
It would be good in the future (as I have asked in the past) if vfs-wide changes like these could spend some time in linux-next so people know what is coming ...
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
Quoted 2 lines · Stephen Rothwell
Merging it into today's linux-next produces conflicts against the ecryptfs and cleancache trees.
How did cleancache end up in linux-next again?
clearcache (Was: Re: [git pull] vfs pile 1)
Hi Christoph,
Quoted 2 lines · On Thu, 13 Jan 2011 03:55:47 -0500 Christoph Hellwig <[email protected]> wrote:
How did cleancache end up in linux-next again?
Um, I asked after the last merge window (on November 17, cc'ing you, Al and Linus) and the only reply I got was from Dan saying that he was hoping to work more on it with some chance of being ready for 2.6.38 ...
So, let me ask again:
"I didn't really follow the discussion at Kernel Summit, but there seemed to be some question as to whether the cleancache stuff will be merged or not. It missed 2.6.37 (obviously), but my question now is do I keep in in linux-next in the hope that it will be merged in 2.6.38? Or is that not going to happen?"
(The cleancache tree has not changed since October 9 last year.)
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
RE: clearcache (Was: Re: [git pull] vfs pile 1)
Quoted 20 lines
Quoted 2 lines · On Thu, 13 Jan 2011 03:55:47 -0500 Christoph Hellwig <[email protected]> wrote:
How did cleancache end up in linux-next again?
Um, I asked after the last merge window (on November 17, cc'ing you, Al and Linus) and the only reply I got was from Dan saying that he was hoping to work more on it with some chance of being ready for 2.6.38
...So, let me ask again:
"I didn't really follow the discussion at Kernel Summit, but there seemed
to be some question as to whether the cleancache stuff will be merged or
not. It missed 2.6.37 (obviously), but my question now is do I keep in in linux-next in the hope that it will be merged in 2.6.38? Or is that not going to happen?"
Quoted 1 line
(The cleancache tree has not changed since October 9 last year.)
Hi Stephen --
Today or tomorrow, I will post a fully-functional in-kernel non-virtualization user for cleancache (and frontswap), called kztmem, which is proposed initially as a staging driver. It will be up to Linus, Andrew, and GregKH to determine if this is acceptable and a sufficient second user of cleancache. Assuming it is, because of the dependency (staging driver dependent on as-yet-unmerged core kernel functionality), I'm not clear yet if/how cleancache should go through linux-next. (Linus's last email on the topic indicated he thought cleancache should go through Andrew.)
So please stay tuned for the next episode in this continuing drama. ;-)
Thanks,
Dan
Re: clearcache (Was: Re: [git pull] vfs pile 1)
In reply to Stephen RothwellQuoted 6 lines · Stephen Rothwell
"I didn't really follow the discussion at Kernel Summit, but there seemed to be some question as to whether the cleancache stuff will be merged or not. It missed 2.6.37 (obviously), but my question now is do I keep in in linux-next in the hope that it will be merged in 2.6.38? Or is that not going to happen?"
The real problem is I don't think anyone is really paying attention to cleancache.
Dan, something that might be useful to drive interest would be a demonstration of this improves performance on, say, a netbook using cleancache and zram, and how it is better than just using zram directly as a swap device. With maybe some numbers? That might get some interest from the community desktop distributions...
- Ted
RE: clearcache (Was: Re: [git pull] vfs pile 1)
Hi Ted --
Thanks for taking the time to reply.
Quoted 2 lines
The real problem is I don't think anyone is really paying attention to cleancache.
It's a bit more complicated than that. There ARE a lot of people interested in it, but there is a bit of a deadlock. I've heard from many people that would love to use Xen transcendent memory as a great solution for memory overcommitment in the cloud, but they get skittish when I tell them it requires kernel changes that haven't been accepted upstream. But key Linux maintainers don't consider the Xen base interesting enough to allow merging of cleancache (and frontswap), despite its simplicity and negligible impact, without at least a second (and preferably in-kernel) user.
Quoted 5 lines
Dan, something that might be useful to drive interest would be a demonstration of this improves performance on, say, a netbook using cleancache and zram, and how it is better than just using zram directly as a swap device. With maybe some numbers? That might get some interest from the community desktop distributions...
Indeed. I was hoping that Nitin's work on zcache (the page cache version of zram) would serve that purpose but GregKH declined to merge it because it was dependent on unmerged cleancache... thus a chicken-and-egg problem; and Nitin has apparently now moved on to other (non-Linux-kernel) things. As a result, I've spent most of my free time over the last three months working on kztmem, which will hopefully serve the purpose. (I had hoped to post V1 of kztmem by today but ran into a problem in an overnight test run. So stay tuned.)
Dan
P.S. The numbers look pretty good.P.P.S. kztmem should also be easily adaptable to KVM, but I haven't
the KVM expertise to make it happen
Re: clearcache (Was: Re: [git pull] vfs pile 1)
Quoted 3 lines · Dan Magenheimer
As a result, I've spent most of my
free time over the last three months working on kztmem, which will hopefully serve the purpose.
You'll have to forgive me, but I have absolutely no idea what kztmem is or what it does. Is it just compressed tmem, and hence, something that is only of interest to people using Xen? If so, it's not clear to me how it will help non-Xen people become interested in these patches.
Regards,
- Ted
RE: clearcache (Was: Re: [git pull] vfs pile 1)
Quoted 9 lines
Quoted 3 lines
As a result, I've spent most of my
free time over the last three months working on kztmem, which will hopefully serve the purpose.You'll have to forgive me, but I have absolutely no idea what kztmem is or what it does. Is it just compressed tmem, and hence, something that is only of interest to people using Xen? If so, it's not clear to me how it will help non-Xen people become interested in these patches.
Ah, sorry, processing too much email backlog and left out some context...
Kztmem is entirely in-kernel, no virtualization required (neither Xen nor KVM). I'll cc you when I post V1 soon but, yes, it is compressed *in-kernel* tmem, a more flexible/dynamic replacement for zcache and possibly also for zram as well, architected and designed to more easily (than zcache/zram) exploit some other directions I plan to take with tmem concepts, including (but not limited to) page-addressable memory (http://marc.info/?l=linux-mm&m=127811271605009).
Kztmem is coded (at least for now) as a staging driver, but uses exactly the proposed cleancache (and frontswap) patches.
Hope that helps!
Dan