On 3/9/22 11:26 PM, Jeff Layton wrote:
> On Tue, 2022-03-08 at 23:25 +, David Howells wrote:
>> From: Jeffle Xu
>>
>> Export fscache_end_operation() to avoid code duplication.
>>
>> Besides, considering the paired fscache_begin_read_operation() is
>> already exported, it shall make sense to
Jeff Layton wrote:
> > - op->store.i_size = max(pos + size, i_size);
> > + op->store.i_size = max(pos + size, ictx->remote_i_size);
>
> Ahh ok, so if i_size is larger than is represented by this write, you'll
> have a zeroed out region until writeback catches up. Makes sense.
That's the way
Jeff Layton wrote:
> This seems like something useful, but I wonder if it'll need some sort
> of serialization vs. concurrent updates.
Quite possibly, though that may be something that we have to delegate to the
network filesystem. kafs, for instance, performs local serialisation of
StoreData R
Jeff Layton wrote:
> > + rreq->work.func = netfs_rreq_work;
> > +
>
> ^^^
> This seems like it should be an INIT_WORK call. I assume you're moving
> this here this because you intend to use netfs_alloc_request for writes
> too?
Interesting question. INIT_WORK() was called in netfs_alloc_requ
On Tue, 2022-03-08 at 23:30 +, David Howells wrote:
> Make afs use netfslib's tracking for the server's idea of what the current
> inode size is independently of inode->i_size. We really want to use this
> value when calculating the new vnode size when initiating a StoreData RPC
> op rather th
On Tue, 2022-03-08 at 23:29 +, David Howells wrote:
> Provide a place in which to keep track of the actual remote file size in
> the netfs context. This is needed because inode->i_size will be updated as
> we buffer writes in the pagecache, but the server file size won't get
> updated until we
On Tue, 2022-03-08 at 23:29 +, David Howells wrote:
> Split fs/netfs/read_helper.c into two pieces, one to deal with buffered
> writes and one to deal with the I/O mechanism.
>
I think you mean buffered reads here?
> Changes
> ===
> ver #2)
> - Add kdoc reference to new file.
>
> Signe
On Wed, 2022-03-09 at 19:23 +, David Howells wrote:
> Jeff Layton wrote:
>
> > > Add a netfs_i_context struct that should be included in the network
> > > filesystem's own inode struct wrapper, directly after the VFS's inode
> > > struct, e.g.:
> > >
> > > struct my_inode {
> > >
On Tue, 2022-03-08 at 23:29 +, David Howells wrote:
> Add a function to do the steps needed to begin a read request, allowing
> this code to be removed from several other functions and consolidated.
>
> Changes
> ===
> ver #2)
> - Move before the unstaticking patch so that some functions
Jeff Layton wrote:
> > Add a netfs_i_context struct that should be included in the network
> > filesystem's own inode struct wrapper, directly after the VFS's inode
> > struct, e.g.:
> >
> > struct my_inode {
> > struct {
> > struct inodevfs_inode;
On Wed, 2022-03-09 at 15:49 +, David Howells wrote:
> Jeff Layton wrote:
>
> > Should you undef EM and E_ here after creating these?
>
> Maybe. So far it hasn't mattered...
>
I wasn't suggesting there was a bug there, more just a code hygiene
thing. With macro names as generic as that (es
On Tue, 2022-03-08 at 23:28 +, David Howells wrote:
> Add a netfs_i_context struct that should be included in the network
> filesystem's own inode struct wrapper, directly after the VFS's inode
> struct, e.g.:
>
> struct my_inode {
> struct {
> struct
On Tue, 2022-03-08 at 23:28 +, David Howells wrote:
> Change the request initialisation function to return an error code so that
> the network filesystem can return a failure (ENOMEM, for example).
>
> This will also allow ceph to abort a ->readahead() op if the server refuses
> to give it a c
On Tue, 2022-03-08 at 23:26 +, David Howells wrote:
> Adjust the netfs_rreq tracepoint to include the origin of the request and
> to increase the size of the "what trace" output strings by a character so
> that "ENCRYPT" and "DECRYPT" will fit without abbreviation.
>
> Signed-off-by: David How
Jeff Layton wrote:
> Should you undef EM and E_ here after creating these?
Maybe. So far it hasn't mattered...
David
--
Linux-cachefs mailing list
Linux-cachefs@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-cachefs
On Tue, 2022-03-08 at 23:26 +, David Howells wrote:
> Split netfs_io_* object handling out into a file that's going to contain
> object allocation, get and put routines.
>
> Signed-off-by: David Howells
> cc: linux-cachefs@redhat.com
>
> Link:
> https://lore.kernel.org/r/164622995118.356493
On Tue, 2022-03-08 at 23:26 +, David Howells wrote:
> Adjust helper function names and comments after mass rename of
> struct netfs_read_*request to struct netfs_io_*request.
>
> Changes
> ===
> ver #2)
> - Make the changes in the docs also.
>
> Signed-off-by: David Howells
> cc: linux-
On Tue, 2022-03-08 at 23:25 +, David Howells wrote:
> netfs has a number of lists of symbols for use in tracing, listed in an
> enum and then listed again in a symbol->string mapping for use with
> __print_symbolic(). This is, however, redundant.
>
> Instead, use the symbol->string mapping li
On Tue, 2022-03-08 at 23:25 +, David Howells wrote:
> Rename netfs_read_*request to netfs_io_*request so that the same structures
> can be used for the write helpers too.
>
> perl -p -i -e 's/netfs_read_(request|subrequest)/netfs_io_$1/g' \
>`git grep -l 'netfs_read_\(sub\|\)request'`
> pe
On Tue, 2022-03-08 at 23:25 +, David Howells wrote:
> From: Jeffle Xu
>
> Export fscache_end_operation() to avoid code duplication.
>
> Besides, considering the paired fscache_begin_read_operation() is
> already exported, it shall make sense to also export
> fscache_end_operation().
>
Not
20 matches
Mail list logo
