* [git pull] vfs pile 1
@ 2011-01-13 5:35 Al Viro
2011-01-13 6:25 ` Stephen Rothwell
0 siblings, 1 reply; 9+ messages in thread
From: Al Viro @ 2011-01-13 5:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-fsdevel
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(-)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [git pull] vfs pile 1
2011-01-13 5:35 [git pull] vfs pile 1 Al Viro
@ 2011-01-13 6:25 ` Stephen Rothwell
2011-01-13 8:55 ` Christoph Hellwig
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Rothwell @ 2011-01-13 6:25 UTC (permalink / raw)
To: Al Viro; +Cc: Linus Torvalds, linux-kernel, linux-fsdevel
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
Hi Al,
On Thu, 13 Jan 2011 05:35:54 +0000 Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
> 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
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 ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [git pull] vfs pile 1
2011-01-13 6:25 ` Stephen Rothwell
@ 2011-01-13 8:55 ` Christoph Hellwig
[not found] ` <20110113214239.1b23b523.sfr@canb.auug.org.au20110113220039.GF31800@thunk.org>
2011-01-13 10:42 ` clearcache (Was: Re: [git pull] vfs pile 1) Stephen Rothwell
0 siblings, 2 replies; 9+ messages in thread
From: Christoph Hellwig @ 2011-01-13 8:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Al Viro, Linus Torvalds, linux-kernel, linux-fsdevel
On Thu, Jan 13, 2011 at 05:25:57PM +1100, Stephen Rothwell wrote:
> Merging it into today's linux-next produces conflicts against the
> ecryptfs and cleancache trees.
How did cleancache end up in linux-next again?
^ permalink raw reply [flat|nested] 9+ messages in thread
* clearcache (Was: Re: [git pull] vfs pile 1)
2011-01-13 8:55 ` Christoph Hellwig
[not found] ` <20110113214239.1b23b523.sfr@canb.auug.org.au20110113220039.GF31800@thunk.org>
@ 2011-01-13 10:42 ` Stephen Rothwell
2011-01-13 16:08 ` Dan Magenheimer
2011-01-13 22:00 ` Ted Ts'o
1 sibling, 2 replies; 9+ messages in thread
From: Stephen Rothwell @ 2011-01-13 10:42 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dan Magenheimer, Al Viro, Linus Torvalds, linux-kernel, linux-fsdevel
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
Hi Christoph,
On Thu, 13 Jan 2011 03:55:47 -0500 Christoph Hellwig <hch@infradead.org> 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.)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: clearcache (Was: Re: [git pull] vfs pile 1)
2011-01-13 10:42 ` clearcache (Was: Re: [git pull] vfs pile 1) Stephen Rothwell
@ 2011-01-13 16:08 ` Dan Magenheimer
2011-01-13 22:00 ` Ted Ts'o
1 sibling, 0 replies; 9+ messages in thread
From: Dan Magenheimer @ 2011-01-13 16:08 UTC (permalink / raw)
To: Stephen Rothwell, Christoph Hellwig
Cc: Al Viro, Linus Torvalds, linux-kernel, linux-fsdevel
> On Thu, 13 Jan 2011 03:55:47 -0500 Christoph Hellwig
> <hch@infradead.org> 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.)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: clearcache (Was: Re: [git pull] vfs pile 1)
2011-01-13 10:42 ` clearcache (Was: Re: [git pull] vfs pile 1) Stephen Rothwell
2011-01-13 16:08 ` Dan Magenheimer
@ 2011-01-13 22:00 ` Ted Ts'o
2011-01-14 21:11 ` Dan Magenheimer
1 sibling, 1 reply; 9+ messages in thread
From: Ted Ts'o @ 2011-01-13 22:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christoph Hellwig, Dan Magenheimer, Al Viro, Linus Torvalds,
linux-kernel, linux-fsdevel
On Thu, Jan 13, 2011 at 09:42:39PM +1100, Stephen Rothwell wrote:
>
> "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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: clearcache (Was: Re: [git pull] vfs pile 1)
2011-01-13 22:00 ` Ted Ts'o
@ 2011-01-14 21:11 ` Dan Magenheimer
2011-01-14 22:35 ` Ted Ts'o
0 siblings, 1 reply; 9+ messages in thread
From: Dan Magenheimer @ 2011-01-14 21:11 UTC (permalink / raw)
To: Ted Ts'o, Stephen Rothwell
Cc: Christoph Hellwig, Al Viro, Linus Torvalds, linux-kernel, linux-fsdevel
Hi Ted --
Thanks for taking the time to reply.
> 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.
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: clearcache (Was: Re: [git pull] vfs pile 1)
2011-01-14 21:11 ` Dan Magenheimer
@ 2011-01-14 22:35 ` Ted Ts'o
2011-01-14 23:28 ` Dan Magenheimer
0 siblings, 1 reply; 9+ messages in thread
From: Ted Ts'o @ 2011-01-14 22:35 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Stephen Rothwell, Christoph Hellwig, Al Viro, Linus Torvalds,
linux-kernel, linux-fsdevel
On Fri, Jan 14, 2011 at 01:11:02PM -0800, Dan Magenheimer wrote:
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: clearcache (Was: Re: [git pull] vfs pile 1)
2011-01-14 22:35 ` Ted Ts'o
@ 2011-01-14 23:28 ` Dan Magenheimer
0 siblings, 0 replies; 9+ messages in thread
From: Dan Magenheimer @ 2011-01-14 23:28 UTC (permalink / raw)
To: Ted Ts'o
Cc: Stephen Rothwell, Christoph Hellwig, Al Viro, Linus Torvalds,
linux-kernel, linux-fsdevel
> > 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-01-14 23:28 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-13 5:35 [git pull] vfs pile 1 Al Viro
2011-01-13 6:25 ` Stephen Rothwell
2011-01-13 8:55 ` Christoph Hellwig
[not found] ` <20110113214239.1b23b523.sfr@canb.auug.org.au20110113220039.GF31800@thunk.org>
2011-01-13 10:42 ` clearcache (Was: Re: [git pull] vfs pile 1) Stephen Rothwell
2011-01-13 16:08 ` Dan Magenheimer
2011-01-13 22:00 ` Ted Ts'o
2011-01-14 21:11 ` Dan Magenheimer
2011-01-14 22:35 ` Ted Ts'o
2011-01-14 23:28 ` Dan Magenheimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).