On Tue, Apr 14, 2015 at 12:23:25PM -0700, Christoph Hellwig wrote:
> On Tue, Apr 14, 2015 at 11:54:08AM -0700, Zach Brown wrote:
> > Is this relying on btrfs range cloning being atomic? It certainly
> > doesn't look atomic. It can modify items across an arbitrarily larg
On Tue, Apr 14, 2015 at 02:29:06PM -0400, J. Bruce Fields wrote:
> On Tue, Apr 14, 2015 at 11:22:41AM -0700, Zach Brown wrote:
> > On Tue, Apr 14, 2015 at 02:19:11PM -0400, J. Bruce Fields wrote:
> > > On Tue, Apr 14, 2015 at 01:16:13PM -0400, Anna Schumaker wrote:
> > &g
On Tue, Apr 14, 2015 at 02:19:11PM -0400, J. Bruce Fields wrote:
> On Tue, Apr 14, 2015 at 01:16:13PM -0400, Anna Schumaker wrote:
> > On 04/14/2015 12:53 PM, Christoph Hellwig wrote:
> > > On Sat, Apr 11, 2015 at 09:04:02AM -0400, Jeff Layton wrote:
> > >> Yuck! How the heck do you clean up the me
> > >> Could we perhaps instead of a length, define a 'pos_in_start' and a
> > >> 'pos_in_end' offset (with the latter being -1 for a full-file copy)
> > >> and then return an 'loff_t' value stating where the copy ended?
> > >
> > > Well, the resulting offset will be set if the caller provided it.
On Fri, Apr 10, 2015 at 06:36:41PM -0400, Trond Myklebust wrote:
> On Fri, Apr 10, 2015 at 6:00 PM, Zach Brown wrote:
> > +
> > +/*
> > + * copy_file_range() differs from regular file read and write in that it
> > + * specifically allows return partial success
-off-by: Zach Brown
---
fs/btrfs/ctree.h | 3 ++
fs/btrfs/file.c | 1 +
fs/btrfs/ioctl.c | 91
3 files changed, 56 insertions(+), 39 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index f9c89ca..f7cfa26 100644
--- a/fs/btrfs
existing destination file
descriptor, not a path.
Currently the high level vfs entry point limits copy offloading to files
on the same mount and super (and not in the same file). This can be
relaxed if we get implementations which can copy between file systems
safely.
Signed-off-by: Zach Brown
---
fs
Hello everyone!
Here's my current attempt at the most basic system call interface for
offloading copying between files. The system call and vfs function
are relatively light wrappers around the file_operation method that
does the heavy lifting.
There was interest at LSF in getting the basic infr
Add sys_copy_file_range to the x86 syscall tables.
Signed-off-by: Zach Brown
---
arch/x86/syscalls/syscall_32.tbl | 1 +
arch/x86/syscalls/syscall_64.tbl | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
index b3560ec
On Mon, Oct 06, 2014 at 11:39:45PM -0700, Christoph Hellwig wrote:
> On Mon, Oct 06, 2014 at 04:40:13PM -0700, Zach Brown wrote:
> > Both of the file target's calls to vfs_fsync_range() got the end offset
> > off by one. The range is inclusive, not exclusive. It would sync
path.
This is untested. I found the errors by inspection while following other
code.
Signed-off-by: Zach Brown
---
drivers/target/target_core_file.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/target/target_core_file.c
b/drivers/target/target_core_file.c
> > I'd just remove this generic teardown callback path entirely. If
> > there's PI state hanging off the iocb tear it down during iocb teardown.
>
> Hmm, I thought aio_complete /was/ iocb teardown time.
Well, usually :). If you build up before aio_run_iocb() then you nead
to teardown in kiocb_
> One thing I'm not sure about: What's the largest IO (in terms of # of blocks,
> not # of struct iovecs) that I can throw at the kernel?
Yeah, dunno. I'd guess big :). I'd hope that the PI code already has a
way to clamp the size of bios if there's a limit to the size of PI data
that can be man
> 's a small number of them with strong semantics because they're a part
> of the syscall ABI.
("There's" a small number of them.. vim troubles :))
- z
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo in
> +static int setup_pi_ext(struct kiocb *req, int is_write)
> +{
> + struct file *file = req->ki_filp;
> + struct io_extension *ext = &req->ki_ioext->ke_kern;
> + void *p;
> + unsigned long start, end;
> + int retval;
> +
> + if (!(file->f_flags & O_DIRECT)) {
> +
> @@ -916,6 +921,17 @@ void aio_complete(struct kiocb *iocb, long res, long
> res2)
> struct io_event *ev_page, *event;
> unsigned long flags;
> unsigned tail, pos;
> + int ret;
> +
> + ret = io_teardown_extensions(iocb);
> + if (ret) {
> + if (!res)
> +
> +static int bio_integrity_generate_verify(struct bio *bio, int operate)
> {
> + if (operate)
> + sector = bio->bi_iter.bi_sector;
> + else
> + sector = bio->bi_integrity->bip_iter.bi_sector;
> + if (operate) {
> + bi->generate_fn(
On Mon, Mar 24, 2014 at 09:22:31AM -0700, Darrick J. Wong wrote:
> This RFC provides a rough implementation of a mechanism to allow
> userspace to attach protection information (e.g. T10 DIF) data to a
> disk write and to receive the information alongside a disk read.
I have some comments for you!
On Fri, Mar 21, 2014 at 03:54:37PM -0700, Darrick J. Wong wrote:
> On Fri, Mar 21, 2014 at 05:44:10PM -0400, Benjamin LaHaise wrote:
>
> > I'm inclined to agree with Zach on this item. Ultimately, we need an
> > extensible data structure that can be grown without completely revising
> > the ABI
On Fri, Mar 21, 2014 at 03:20:25PM -0700, Darrick J. Wong wrote:
> On Fri, Mar 21, 2014 at 11:23:32AM -0700, Zach Brown wrote:
> > On Thu, Mar 20, 2014 at 09:30:41PM -0700, Darrick J. Wong wrote:
> > > This RFC provides a rough implementation of a mechanism to allow
> &g
On Fri, Mar 21, 2014 at 02:39:59PM -0700, Darrick J. Wong wrote:
> On Fri, Mar 21, 2014 at 10:57:31AM -0400, Jeff Moyer wrote:
> > "Darrick J. Wong" writes:
> >
> > > This RFC provides a rough implementation of a mechanism to allow
> > > userspace to attach protection information (e.g. T10 DIF) d
On Thu, Mar 20, 2014 at 09:30:41PM -0700, Darrick J. Wong wrote:
> This RFC provides a rough implementation of a mechanism to allow
> userspace to attach protection information (e.g. T10 DIF) data to a
> disk write and to receive the information alongside a disk read. The
> interface is an extensi
Discussing copy offloading at LSF is appropriate because it can involve
so many layers of the stack:
- high level syscall interface
- in-kernel high level entry point for nfsd
- fs specific implementations (btrfs and ocfs2 cow, nfs)
- vfs helper for offloading block copies for ext*,xfs
- b
On Mon, Aug 26, 2013 at 10:02:59PM +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> Hi folks,
>
> This -v2 series adds support to target-core for generic EXTENDED_COPY offload
> emulation as defined by SPC-4 using virtual (IBLOCK, FILEIO, RAMDISK)
> backends.
Cool, thanks for
On Thu, Feb 07, 2013 at 11:19:59AM -0500, Jeff Moyer wrote:
> Boaz Harrosh writes:
> >>
> >> For aio we just need to add additional fields to an existing structure.
> >>
> >> So yeah, I'd be interested in that discussion as well.
>
> Sure, it's easy to start there, but then you eventually end u
25 matches
Mail list logo
