a_ops->perform_write() was left out from Nick Piggin's new a_ops
patchset, as it was non-essential, and postponed for later inclusion.
This short series reintroduces it, but only adds the fuse
implementation and not simple_perform_write(), which I'm not sure
would be a significant improvement.
This allows larger than 4k buffered writes for fuse, which is one of
the most requested features.
This goes on top of the "fuse: writable mmap" patches.
Thanks,
Miklos
--
On Mon, Feb 04, 2008 at 06:04:10PM +0100, Miklos Szeredi wrote:
> a_ops->perform_write() was left out from Nick Piggin's new a_ops
> patchset, as it was non-essential, and postponed for later inclusion.
>
> This short series reintroduces it, but only adds the fuse
> implementation and not simple_perform_write(), which I'm not sure
> would be a significant improvement.
>
> This allows larger than 4k buffered writes for fuse, which is one of
> the most requested features.
>
> This goes on top of the "fuse: writable mmap" patches.
Please don't do this, but rather implement your own .aio_write. There's
very little in generic_file_aio_write that wouldn't be handle by
->perform_write and we should rather factor those up or move to higher
layers than adding this ill-defined abstraction.
> > a_ops->perform_write() was left out from Nick Piggin's new a_ops
> > patchset, as it was non-essential, and postponed for later inclusion.
> >
> > This short series reintroduces it, but only adds the fuse
> > implementation and not simple_perform_write(), which I'm not sure
> > would be a significant improvement.
> >
> > This allows larger than 4k buffered writes for fuse, which is one of
> > the most requested features.
> >
> > This goes on top of the "fuse: writable mmap" patches.
>
> Please don't do this, but rather implement your own .aio_write. There's
> very little in generic_file_aio_write that wouldn't be handle by
> ->perform_write and we should rather factor those up or move to higher
> layers than adding this ill-defined abstraction.
>
Moving up to higher layers might not be possible, due to lock/unlock
of i_mutex being inside generic_file_aio_write().
But with fuse being the only user, it's not a huge issue duplicating
some code.
Nick, were there any other candidates, that would want to use such an
interface in the future?
Thanks,
Miklos
On Mon, Feb 04, 2008 at 09:52:06PM +0100, Miklos Szeredi wrote:
> Moving up to higher layers might not be possible, due to lock/unlock
> of i_mutex being inside generic_file_aio_write().
Well some bits can be moved up. Here's my grand plan which I plan
to implement once I get some time for it (or let someone else do
if they beat me):
- generic_segment_checks goes to fs/read_write.c before caling into
the filesystem
- dito for vfs_check_frozen
- generic_write_checks is a suitable helper already
- dito for remove_suid
- dito for file_update_time
- after that there's not a whole lot left in generic_file_aio_write,
except for direct I/O handling which will probably be very fs-specific
if you have your own buffered I/O code
generic_file_buffered_write is an almost trivial wrapper around what's
->perform_write in Nick's earlier patches and a helper for the syncing
activity.
>
> But with fuse being the only user, it's not a huge issue duplicating
> some code.
>
> Nick, were there any other candidates, that would want to use such an
> interface in the future?
>
> Thanks,
> Miklos
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---