Hmm I could not reproduce this with the latest state (ef9bf3b7144bee6ce) of branch 'origin/for-next' from git.infradead.org/users/eparis/notify.git What i did was: - register with fanotify - set mark for OPEN_PERM event - read an event - cause a segfault before response is returned to fanotify The process terminates and the core file is created as expected. I dont think that this will work. A fanotify registration is not tracked by its pid, but by its group which may be valid ...

__user only makes sense on pointers. Just make this a "struct metadata_incore_ent __user *", which will also take care of the We usually try hard to avoid ioctls with indirect pointers in them. The implementation is correct (most people get this wrong), besides the extraneous __user keyword in there. Have you tried passing just a single metadata_incore_ent at the ioctl and looping in user space? I would guess the extra overhead of that would be small enough, but that might need to be ...

Signed-off-by: J. Bruce Fields <bfields@redhat.com> --- fs/locks.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 5cb6506..feaac63 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -1399,7 +1399,7 @@ int generic_setlease(struct file *filp, long arg, struct file_lock **flp) for (before = &inode->i_flock; ((fl = *before) != NULL) && IS_LEASE(fl); before = &fl->fl_next) { - if (fl->fl_file == lease->fl_file) + if (fl->fl_file == ...

The nfs server only supports read delegations for now, so we don't care how conflicts are determined. All we care is that unlocks are recognized as matching the leases they are meant to remove. After the last patch, a comparison of struct files will work for that purpose. So we no longer need this callback. Signed-off-by: J. Bruce Fields <bfields@redhat.com> --- fs/locks.c | 8 +------- fs/nfsd/nfs4state.c | 21 +-------------------- include/linux/fs.h | 1 - 3 files ...

A couple lock manager calls used by the lease code look unnecessary to me; the following patches remove them. I'm planning on submitting them with the nfsd patches for 2.6.38, barring any objections. --b. --

Please also update Documentation/filesystems/Locking for method removals. --

There is no problem with having a method (let's call it write_inode for simplicity, it could be sync_inode or got knows what else) to write clear the dirty state of the VFS inode asynchronously, as long as we make sure the bits are only updated once it's been successfull. That is for an async call we can't let the caller of ->write_inode update The problem is that currently we almost never do a pure blocking ->write_inode. The way the sync code is written we always do a non-blocking one ...

Is it not possible to enhance the existing readahead mechanisms to work on metadata as well? Is there some reason why metadata should be fetched separately from the data it references? Cheers, Jeff --

Sorry, it was the commit 93bb41f4f8b89ac8 ("fs: Do not dispatch FITRIM through separate super_operation"). --

OK I missed that part about not requiring dirty metadata to be written, just currently ongoing async operations. But then I don't understand how it would be used by nfsd, how does nfsd start some async operation on the inode metadata such that ->commit_metadata would do anything useful for it? --

Implementation btrfs .metadata_readahead. In btrfs, all metadata pages are in a special btree_inode. We do readahead in it. Signed-off-by: Shaohua Li <shaohua.li@intel.com> --- fs/btrfs/disk-io.c | 10 ++++++++++ fs/btrfs/super.c | 1 + fs/btrfs/volumes.c | 38 ++++++++++++++++++++++++++++++++++++++ fs/btrfs/volumes.h | 2 ++ mm/readahead.c | 1 + 5 files changed, 52 insertions(+) Index: ...

Implement btrfs specific .metadata_incore. In btrfs, all metadata pages are in a special btree_inode, we take pages from it. we only account updated and referenced pages here. Say we collect metadata info in one boot, do metadata readahead in next boot and we might collect metadata again. The readahead could read garbage data in as metadata could be changed from first run. If we only account updated pages, the metadata info collected by userspace will increase every run. Btrfs alloc_extent_buffer ...

Hi, We have file readahead to do asyn file read, but has no metadata readahead. For a list of files, their metadata is stored in fragmented disk space and metadata read is a sync operation, which impacts the efficiency of readahead much. The patches try to add meatadata readahead for btrfs. In btrfs, metadata is stored in btree_inode. Ideally, if we could hook the inode to a fd so we could use existing syscalls (readahead, mincore or upcoming fincore) to do readahead, but the inode is ...