Btrfs devel - Sep 2012 - [PATCH] 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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Anand Jain <anand.jain@oracle.com>

Developing service cmds needs it.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
 cmds-send.c |   15 +++++++++------
 commands.h  |    8 ++++++++
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/cmds-send.c b/cmds-send.c
index 41ea523..9e94410 100644
--- a/cmds-send.c
+++ b/cmds-send.c
@@ -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",
diff --git a/commands.h b/commands.h
index bb6d2dd..c65ba20 100644
--- a/commands.h
+++ b/commands.h
@@ -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;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Anand Jain <anand.jain@oracle.com>

Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
 send.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/send.h b/send.h
index 9934e94..1bf4f32 100644
--- a/send.h
+++ b/send.h
@@ -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
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Anand Jain <anand.jain@oracle.com>

Developing service cmds needs it.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
 fs/btrfs/send.c |   11 ++++++-----
 fs/btrfs/send.h |    1 +
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index fb5ffe9..89411b3 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -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;
diff --git a/fs/btrfs/send.h b/fs/btrfs/send.h
index 9934e94..1bf4f32 100644
--- a/fs/btrfs/send.h
+++ b/fs/btrfs/send.h
@@ -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
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, Sep 14, 2012 at 01:50:24PM +0800, anand jain
wrote:
>  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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

>>   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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Sep 17, 2012 at 12:48:10PM +0800, Anand Jain
wrote:
> 
> >>  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.

-- 
=== 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.

On Mon, Sep 17, 2012 at 12:48:10PM +0800, Anand Jain
wrote:
> >>  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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

>     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.
>     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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

>>> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Sep 18, 2012 at 01:33:29PM +0800, Anand Jain
wrote:
>   ''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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html