Btrfs + Btrfs-progs: make pipe functions re-usable
PATCH 1/1 Btrfs + Btrfs-progs: make pipe functions re-usable
btrfs send introduced a part of code to read kernel-data from user-end using pipe. We need this part of code to be useable outside of send sub-cmd, so that developing service sub-cmd can use it.
Following this email are the patches for this purpose.
Thanks, Anand
PATCH 1/1 Btrfs-progs: make dump_thread and write_buf usable outside cmds-send.c
From: Anand Jain <[email protected]>
Developing service cmds needs it.
--- cmds-send.c | 15 +++++++++------ commands.h | 8 ++++++++ 2 files changed, 17 insertions(+), 6 deletions(-)
cmds-send.c +9 -6
@@ -175,7 +175,7 @@ static void add_clone_source(struct btrfs_send *s, u64 root_id) s->clone_sources[s->clone_sources_count++] = root_id; } -static int write_buf (int fd,const void *buf,int size) +int write_buf (int fd,const void *buf,int size) {int ret;int pos =0 ;
@@ -202,15 +202,15 @@ out:return ret; } -static void *dump_thread (void *arg_) +void *dump_thread (void *arg_) {int ret; -struct btrfs_send *s = (struct btrfs_send *)arg_; +struct btrfs_dump *d = (struct btrfs_dump *)arg_;char buf[4096 ];int readed;while (1 ) { - readed =read (s->send_fd, buf,sizeof (buf)); + readed =read (d->from_fd, buf,sizeof (buf));if (readed <0 ) { ret = -errno; fprintf(stderr, "ERROR: failed to read stream from "
@@ -221,7 +221,7 @@ static void *dump_thread(void *arg_) ret =0 ; goto out; } - ret =write_buf (s->dump_fd, buf, readed); + ret =write_buf (d->to_fd, buf, readed);if (ret <0 ) goto out; }
@@ -241,6 +241,7 @@ static int do_send(struct btrfs_send *send, u64 root_id, u64 parent_root)pthread_attr_t t_attr;struct btrfs_ioctl_send_args io_send;struct subvol_info *si; +struct btrfs_dump dump;void *t_err =NULL ;int subvol_fd =-1 ;int pipefd[2 ];
@@ -273,10 +274,12 @@ static int do_send(struct btrfs_send *send, u64 root_id, u64 parent_root) io_send.send_fd = pipefd[1 ]; send->send_fd = pipefd[0 ]; + dump.from_fd = pipefd[0 ]; + dump.to_fd = send->dump_fd;if (!ret) ret =pthread_create (&t_read, &t_attr, dump_thread, - send); + &dump);if (ret) { ret = -ret; fprintf(stderr, "ERROR: thread setup failed: %s\n",
commands.h +8 -0
@@ -82,6 +82,14 @@ void help_command_group(const struct cmd_group *grp, int argc, char **argv);/* common.c */ int open_file_or_dir (const char *fname); +/* cmds-send.c */ +int write_buf (int fd,const void *buf,int size); +void *dump_thread (void *arg_); +struct btrfs_dump { +int from_fd; +int to_fd; +}; +extern const struct cmd_group subvolume_cmd_group;extern const struct cmd_group filesystem_cmd_group;extern const struct cmd_group balance_cmd_group;
Signature · 1 line
1.7.1
PATCH 1/1 Btrfs: write_buf is now callable outside send.c
From: Anand Jain <[email protected]>
Developing service cmds needs it.
--- fs/btrfs/send.c | 11 ++++++----- fs/btrfs/send.h | 1 + 2 files changed, 7 insertions(+), 5 deletions(-)
fs/btrfs/send.c +6 -5
@@ -377,7 +377,7 @@ static struct btrfs_path *alloc_path_for_send(void)return path; } -static int write_buf (struct send_ctx *sctx,const void *buf,u32 len) +int write_buf (struct file *filp,const void *buf,u32 len,loff_t *off) {int ret;mm_segment_t old_fs;
@@ -387,8 +387,7 @@ static int write_buf(struct send_ctx *sctx, const void *buf, u32 len)set_fs (KERNEL_DS );while (pos < len) { - ret =vfs_write (sctx->send_filp, (char *)buf + pos, len - pos, - &sctx->send_off); + ret =vfs_write (filp, (char *)buf + pos, len - pos, off);/* TODO handle that correctly */ /*if (ret == -ERESTARTSYS) { continue;
@@ -544,7 +543,8 @@ static int send_header(struct send_ctx *sctx)strcpy (hdr.magic,BTRFS_SEND_STREAM_MAGIC ); hdr.version =cpu_to_le32 (BTRFS_SEND_STREAM_VERSION ); -return write_buf (sctx, &hdr,sizeof (hdr)); +return write_buf (sctx->send_filp, &hdr,sizeof (hdr), + &sctx->send_off); }/*
@@ -581,7 +581,8 @@ static int send_cmd(struct send_ctx *sctx) crc =crc32c (0 , (unsigned char *)sctx->send_buf, sctx->send_size); hdr->crc =cpu_to_le32 (crc); - ret =write_buf (sctx, sctx->send_buf, sctx->send_size); + ret =write_buf (sctx->send_filp, sctx->send_buf, sctx->send_size, + &sctx->send_off); sctx->total_send_size += sctx->send_size; sctx->cmd_send_size[le16_to_cpu (hdr->cmd)] += sctx->send_size;
fs/btrfs/send.h +1 -0
@@ -130,4 +130,5 @@ enum {#ifdef __KERNEL__long btrfs_ioctl_send (struct file *mnt_file,void __user *arg); +int write_buf (struct file *filp,const void *buf,u32 len,loff_t *off);#endif
Signature · 1 line
1.7.1
PATCH 1/1 Btrfs-progs: making send.h inline with its kernel side change
In reply to Anand jainFrom: Anand Jain <[email protected]>
--- send.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
send.h +1 -0
@@ -130,4 +130,5 @@ enum {#ifdef __KERNEL__long btrfs_ioctl_send (struct file *mnt_file,void __user *arg); +int write_buf (struct file *filp,const void *buf,u32 len,loff_t *off);#endif
Signature · 1 line
1.7.1
Quoted 4 lines · anand jain
btrfs send introduced a part of code to read kernel-data from user-end using pipe. We need this part of code to be useable outside of send sub-cmd, so that developing service sub-cmd can use it.
What's 'service sub-cmd' please?
david
Quoted 7 lines
Quoted 5 lines
btrfs send introduced a part of code to read kernel-data from user-end using pipe. We need this part of code to be useable outside of send sub-cmd, so that developing service sub-cmd can use it.
What's 'service sub-cmd' please?
at the moment 'btrfs service history <mnt>|<dev>' to show logs of maintenance. comments/suggestions welcome.
Thanks
-Anand
Quoted 11 lines · Anand Jain
Quoted 7 lines
Quoted 5 lines
btrfs send introduced a part of code to read kernel-data from user-end using pipe. We need this part of code to be useable outside of send sub-cmd, so that developing service sub-cmd can use it.
What's 'service sub-cmd' please?
at the moment 'btrfs service history <mnt>|<dev>' to show logs of maintenance. comments/suggestions welcome.
As I said in our private email exchange some months ago, I don't
think this is the right way to be doing this. For example, if you use an alternative tool (such as btrfs-gui) which uses the ioctls directly, you've lost that logging information.
Keeping a log of what's been done to the FS is much better done by
extending the available logging in the kernel (and making it a compile-time option for those who don't want or need it). You can then write a simple shell script to chomp through the normal kernel logs to extract this information.
Hugo.
Signature · 4 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- I'll take your bet, but make it ten thousand francs. I'm only ---
a _poor_ corrupt official. Quoted 5 lines
As I said in our private email exchange some months ago, I don't
think this is the right way to be doing this. For example, if you use an alternative tool (such as btrfs-gui) which uses the ioctls directly, you've lost that logging information.
I agree with that Hugo. Thanks. These changes are partly for the same reason.
Quoted 2 lines
Keeping a log of what's been done to the FS is much better done by
extending the available logging in the kernel
Could you please point out the modules you are talking about. I reviewed some but just in case if I have missed out any.
Thanks, Anand
Quoted 10 lines · Anand Jain
Quoted 6 lines
Quoted 4 lines
btrfs send introduced a part of code to read kernel-data from user-end using pipe. We need this part of code to be useable outside of send sub-cmd, so that developing service sub-cmd can use it.
What's 'service sub-cmd' please?
at the moment 'btrfs service history <mnt>|<dev>' to show logs of maintenance. comments/suggestions welcome.
Sorry, but without a more detailed description I can hardly give useful comments. The patch looks ok but stands alone, you can post it with your proposed feature together.
david
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
What's 'service sub-cmd' please?
at the moment 'btrfs service history<mnt>|<dev>' to show logs of maintenance. comments/suggestions welcome.
Sorry, but without a more detailed description I can hardly give useful comments.
David,
'btrfs service history <mnt>|<dev>'
is basically to show the list of cli/gui commands which are successfully run on the btrfs as part of its - creation (may be), configuration and maintenance.
HTH.
Thanks, Anand
Quoted 4 lines · Anand Jain
'btrfs service history <mnt>|<dev>'
is basically to show the list of cli/gui commands which are successfully run on the btrfs as part of its - creation (may be), configuration and maintenance.
Is it modelled after ZFS 'zpool history' command? AFAICS it captures actions modifiying the pools, there's nothing similar for btrfs.
david