From: David Howells <dhowells@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: David Howells <dhowells@redhat.com>,
torvalds@osdl.org, steved@redhat.com, sct@redhat.com,
aviro@redhat.com, linux-fsdevel@vger.kernel.org,
linux-cachefs@redhat.com, nfsv4@linux-nfs.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/7] FS-Cache: CacheFiles: A cache that backs onto a mounted filesystem
Date: Fri, 21 Apr 2006 15:49:57 +0100 [thread overview]
Message-ID: <24065.1145630997@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <20060420181616.0f167b1d.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
> > +unsigned long cachefiles_debug = 0;
>
> Unneeded initialisation.
Yep.
> > +static int cachefiles_init(void)
>
> __init?
Yep.
> removeable?
Yep.
> hm, what's going on here? It's strange for a callee to undo an i_mutex
> which some caller took.
It happens occasionally. The problem here is that I want to call this from
three different places, but if I drop the mutex before calling the burial
function, I have to get the mutex again to do the unlink; but as it is, I have
to drop it before I can do the rename:-/
It's not nice, but...
You have to note also that the directory's i_mutex is quite important for
interacting with the daemon also. The wonders of working through an existing
filesystem, and the the wonders of co-operating with userspace.
> > +int
> > +generic_file_buffered_write_one_kernel_page(struct file *file,
> > + pgoff_t index,
> > + struct page *src)
>
> Some covering comments would be nice.
I copied those of generic_file_buffered_write() and rearranged them a bit:-)
I'll add a comment to my function.
> If the hosts's i_mutex is held (it should be, but there are no comments)
> then we can read inode->i_size directly. Minor thing.
Ah. Do we though? I just copied generic_file_buffered_write() and cut it
down. The same is done there. The comments at the top of that function
weren't exactly forthcoming on the preconditions for calling that function.
> that's copy_highpage().
Good point.
> Sigh. It's all a huge pile of new code. And it's only used by AFS, the
> number of users of which can be counted on the fingers of one foot. An NFS
> implementation would make a testing phase much more useful.
Yes... Whilst I have it working with NFS, the NFS anti-aliasing problems are
still there and still need to be sorted. I thought I'd got them nailed, but
then Trond changed his mind:-(
But that does not preclude putting what I can release up for review.
David
WARNING: multiple messages have this Message-ID (diff)
From: David Howells <dhowells@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: aviro@redhat.com, sct@redhat.com, nfsv4@linux-nfs.org,
steved@redhat.com, linux-kernel@vger.kernel.org,
David Howells <dhowells@redhat.com>,
torvalds@osdl.org, linux-cachefs@redhat.com,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 7/7] FS-Cache: CacheFiles: A cache that backs onto a mounted filesystem
Date: Fri, 21 Apr 2006 15:49:57 +0100 [thread overview]
Message-ID: <24065.1145630997@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <20060420181616.0f167b1d.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
> > +unsigned long cachefiles_debug = 0;
>
> Unneeded initialisation.
Yep.
> > +static int cachefiles_init(void)
>
> __init?
Yep.
> removeable?
Yep.
> hm, what's going on here? It's strange for a callee to undo an i_mutex
> which some caller took.
It happens occasionally. The problem here is that I want to call this from
three different places, but if I drop the mutex before calling the burial
function, I have to get the mutex again to do the unlink; but as it is, I have
to drop it before I can do the rename:-/
It's not nice, but...
You have to note also that the directory's i_mutex is quite important for
interacting with the daemon also. The wonders of working through an existing
filesystem, and the the wonders of co-operating with userspace.
> > +int
> > +generic_file_buffered_write_one_kernel_page(struct file *file,
> > + pgoff_t index,
> > + struct page *src)
>
> Some covering comments would be nice.
I copied those of generic_file_buffered_write() and rearranged them a bit:-)
I'll add a comment to my function.
> If the hosts's i_mutex is held (it should be, but there are no comments)
> then we can read inode->i_size directly. Minor thing.
Ah. Do we though? I just copied generic_file_buffered_write() and cut it
down. The same is done there. The comments at the top of that function
weren't exactly forthcoming on the preconditions for calling that function.
> that's copy_highpage().
Good point.
> Sigh. It's all a huge pile of new code. And it's only used by AFS, the
> number of users of which can be counted on the fingers of one foot. An NFS
> implementation would make a testing phase much more useful.
Yes... Whilst I have it working with NFS, the NFS anti-aliasing problems are
still there and still need to be sorted. I thought I'd got them nailed, but
then Trond changed his mind:-(
But that does not preclude putting what I can release up for review.
David
next prev parent reply other threads:[~2006-04-21 14:50 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-20 16:59 [PATCH 1/7] FS-Cache: Provide a filesystem-specific sync'able page bit David Howells
2006-04-20 16:59 ` [PATCH 2/7] FS-Cache: Add notification of page becoming writable to VMA ops David Howells
2006-04-20 17:40 ` Zach Brown
2006-04-20 18:27 ` Anton Altaparmakov
2006-04-20 16:59 ` [PATCH 3/7] FS-Cache: Avoid ENFILE checking for kernel-specific open files David Howells
2006-04-20 17:18 ` Christoph Hellwig
2006-04-20 18:06 ` David Howells
2006-04-20 18:06 ` David Howells
2006-04-21 0:11 ` Andrew Morton
2006-04-21 0:11 ` Andrew Morton
2006-04-21 10:57 ` David Howells
2006-04-21 10:57 ` David Howells
2006-04-21 0:07 ` Andrew Morton
2006-04-21 0:07 ` Andrew Morton
2006-04-21 12:33 ` David Howells
2006-04-21 12:33 ` David Howells
2006-04-21 18:22 ` Andrew Morton
2006-04-21 18:22 ` Andrew Morton
2006-04-21 19:29 ` David Howells
2006-04-21 19:29 ` David Howells
2006-04-20 16:59 ` [PATCH 4/7] FS-Cache: Export find_get_pages() David Howells
2006-04-20 17:19 ` Christoph Hellwig
2006-04-20 17:19 ` Christoph Hellwig
2006-04-20 17:45 ` David Howells
2006-04-20 17:45 ` David Howells
2006-04-21 0:15 ` Andrew Morton
2006-04-21 0:15 ` Andrew Morton
2006-04-21 13:02 ` David Howells
2006-04-21 13:02 ` David Howells
2006-04-20 16:59 ` [PATCH 5/7] FS-Cache: Generic filesystem caching facility David Howells
2006-04-21 0:46 ` Andrew Morton
2006-04-21 0:46 ` Andrew Morton
2006-04-21 14:15 ` David Howells
2006-04-21 14:15 ` David Howells
2006-04-21 18:38 ` Andrew Morton
2006-04-21 18:38 ` Andrew Morton
2006-04-21 19:33 ` David Howells
2006-04-21 19:33 ` David Howells
2006-04-20 16:59 ` [PATCH 6/7] FS-Cache: Make kAFS use FS-Cache David Howells
2006-04-20 16:59 ` [PATCH 7/7] FS-Cache: CacheFiles: A cache that backs onto a mounted filesystem David Howells
2006-04-21 0:57 ` Andrew Morton
2006-04-21 0:57 ` Andrew Morton
2006-04-21 1:16 ` Andrew Morton
2006-04-21 1:16 ` Andrew Morton
2006-04-21 14:49 ` David Howells [this message]
2006-04-21 14:49 ` David Howells
2006-04-21 0:12 ` [PATCH 1/7] FS-Cache: Provide a filesystem-specific sync'able page bit Andrew Morton
2006-04-21 0:12 ` Andrew Morton
2006-04-21 10:22 ` David Howells
2006-04-21 10:22 ` David Howells
2006-04-21 10:33 ` Andrew Morton
2006-04-21 10:33 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24065.1145630997@warthog.cambridge.redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@osdl.org \
--cc=aviro@redhat.com \
--cc=linux-cachefs@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=sct@redhat.com \
--cc=steved@redhat.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.