Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Marat Khalili]

On 25/09/17 17:33, Qu Wenruo wrote:
(Any in this case, anyone in the maillist can help review messages) 
If this is a question, I can help with assigning levels to messages. 
Although I think many levels are only required for complex daemons or 
network tools, while btrfs utils mostly perform atomic operations which 
either succeed or fail. But it's of course hard to be sure without 
seeing all actual messages, probably there's some use for 4 levels.


--

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

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Qu Wenruo]

On 2017年09月25日 22:19, Hugo Mills wrote:

On Mon, Sep 25, 2017 at 04:04:03PM +0800, Qu Wenruo wrote:



On 2017年09月25日 15:52, Hugo Mills wrote:

On Mon, Sep 25, 2017 at 03:46:15PM +0800, Qu Wenruo wrote:



On 2017年09月25日 15:42, Marat Khalili wrote:

On 25/09/17 10:30, Nikolay Borisov wrote:

On 19.09.2017 10:41, Misono, Tomohiro wrote:

"btrfs subvolume create/delete" outputs the message of "Create/Delete
subvolume ..." even when an operation fails.
Since it is confusing, let's outputs the message only when an
operation succeeds.

Please change the verb to past tense, more strongly signaling success -
i.e. "Created subvolume"

What about recalling some UNIX standards and returning to NOT
outputting any message when operation succeeds? My scripts are
full of grep -v calls after each btrfs command, and this sucks
(and I don't think I'm alone in this situation).


Isn't the correct way to catch the return value instead of grepping
the output?


It is, but if, for example, you're using the command in a cron
script which is expected to work, you don't want it producing output
because then you get a mail every time the script runs. So you have to
grep -v on the "success" output to make the successful script silent.


What about redirecting stdout to /dev/null and redirecting stderr to
mail if return value is not 0?
As for expected-to-work case, the stdout doesn't has much meaning
and return value should be good enough to judge the result.




If it's some command not returning value properly, would you please
report it as a bug so we can fix it.


It's not the return value that's problematic (although those used
to be a real mess). It's the fact that a successful run of the command
produces noise on stdout, which most commands don't.


Yes, a lot of tried-and-true tools don't output anything for
successful run, but also a lot of other tools do output something by
default, especially for complex tools like LVM.


btrfs sub create and btrfs sub delete, though, aren't complex.
They're about as complex as mkdir and rmdir, from a user point of
view. What's more, and like mkdir/rmdir, the effects of those commands
show up in the filesystem at the path given, so manual verification
could be as simple as "ls -d !$" or "ls !$/..". It's really, really
not necessary to have this command unconditionally print "yes, I
created a directory for you" to stdout.

Yes, there's ways to deal with it in shell scripts, but wouldn't
life be so much better if you didn't have to? Like you don't have to
filter out success reports from mkdir.


Maybe we can introduce a global --quite option to silent some output.


Or drop the spurious output unless it's asked for with --verbose.
Because then it makes it so much easier to compose tools together into
bigger and more complex things, which is, after all, one of the
fundamental things that UNIX does right.

I think we need at least 4 levels of message: debug, info, warn, error.
And only show debug and higher for --verbose.
Default to show info, and warn/error always get show (stderr).
(And during the new framework, we can add support for translation)

And we also need to reassign all existing message to new message level.

It may be time consuming but we just need to do it since there is real 
user demand here.

(Any in this case, anyone in the maillist can help review messages)

Thanks,
Qu



Hugo.


Thanks,
Qu


Hugo.

Thanks,
Qu


If you change the message a lot of scripts will have to be
changed, at least make it worth it.

  --

With Best Regards,
Marat Khaliili






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

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Hugo Mills]

On Mon, Sep 25, 2017 at 04:04:03PM +0800, Qu Wenruo wrote:
> 
> 
> On 2017年09月25日 15:52, Hugo Mills wrote:
> >On Mon, Sep 25, 2017 at 03:46:15PM +0800, Qu Wenruo wrote:
> >>
> >>
> >>On 2017年09月25日 15:42, Marat Khalili wrote:
> >>>On 25/09/17 10:30, Nikolay Borisov wrote:
> On 19.09.2017 10:41, Misono, Tomohiro wrote:
> >"btrfs subvolume create/delete" outputs the message of "Create/Delete
> >subvolume ..." even when an operation fails.
> >Since it is confusing, let's outputs the message only when an
> >operation succeeds.
> Please change the verb to past tense, more strongly signaling success -
> i.e. "Created subvolume"
> >>>What about recalling some UNIX standards and returning to NOT
> >>>outputting any message when operation succeeds? My scripts are
> >>>full of grep -v calls after each btrfs command, and this sucks
> >>>(and I don't think I'm alone in this situation).
> >>
> >>Isn't the correct way to catch the return value instead of grepping
> >>the output?
> >
> >It is, but if, for example, you're using the command in a cron
> >script which is expected to work, you don't want it producing output
> >because then you get a mail every time the script runs. So you have to
> >grep -v on the "success" output to make the successful script silent.
> 
> What about redirecting stdout to /dev/null and redirecting stderr to
> mail if return value is not 0?
> As for expected-to-work case, the stdout doesn't has much meaning
> and return value should be good enough to judge the result.
> 
> >
> >>If it's some command not returning value properly, would you please
> >>report it as a bug so we can fix it.
> >
> >It's not the return value that's problematic (although those used
> >to be a real mess). It's the fact that a successful run of the command
> >produces noise on stdout, which most commands don't.
> 
> Yes, a lot of tried-and-true tools don't output anything for
> successful run, but also a lot of other tools do output something by
> default, especially for complex tools like LVM.

   btrfs sub create and btrfs sub delete, though, aren't complex.
They're about as complex as mkdir and rmdir, from a user point of
view. What's more, and like mkdir/rmdir, the effects of those commands
show up in the filesystem at the path given, so manual verification
could be as simple as "ls -d !$" or "ls !$/..". It's really, really
not necessary to have this command unconditionally print "yes, I
created a directory for you" to stdout.

   Yes, there's ways to deal with it in shell scripts, but wouldn't
life be so much better if you didn't have to? Like you don't have to
filter out success reports from mkdir.

> Maybe we can introduce a global --quite option to silent some output.

   Or drop the spurious output unless it's asked for with --verbose.
Because then it makes it so much easier to compose tools together into
bigger and more complex things, which is, after all, one of the
fundamental things that UNIX does right.

   Hugo.

> Thanks,
> Qu
> >
> >Hugo.
> >>Thanks,
> >>Qu
> >>
> >>>If you change the message a lot of scripts will have to be
> >>>changed, at least make it worth it.
> >>>
> >>>  --
> >>>
> >>>With Best Regards,
> >>>Marat Khaliili
> >>>
> >

-- 
Hugo Mills | Great films about cricket: The Fantastic Four
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4  |


signature.asc
Description: Digital signature

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Marat Khalili]

On 25/09/17 11:08, Qu Wenruo wrote:
What about redirecting stdout to /dev/null and redirecting stderr to 
mail if return value is not 0?

s/if return value is not 0/if return value is 0/.

The main point is, if btrfs returns 0, then nothing to worry about.
(Unless there is a bug, even in that case keep an eye on stderr should 
be enough to catch that)


Redirection to /dev/null will work. However,

1) It will always looks suspicious. grep -v with expected message is at 
least clear about its intent and consequences.


2) Although shorter than grep -v, it will still take space in shell 
scripts and force one to remember btrfs commands one has to add it 
after. This is already inconvenient enough to want a fix.


--

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

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Marat Khalili]

On 25/09/17 10:52, Hugo Mills wrote:


Isn't the correct way to catch the return value instead of grepping
the output?
It is, but if, for example, you're using the command in a cron
script which is expected to work, you don't want it producing output
because then you get a mail every time the script runs. So you have to
grep -v on the "success" output to make the successful script silent.


If it's some command not returning value properly, would you please
report it as a bug so we can fix it.

It's not the return value that's problematic (although those used
to be a real mess). It's the fact that a successful run of the command
produces noise on stdout, which most commands don't.
Yes, exactly: cron, mail -E and just long scripts where btrfs operations 
are small steps here and there.


(On top of this, actually catching the return value from the right 
command before `| grep -v` with errexit and pipefail on is so difficult 
that I usually end up rewriting whole mess in Python. Which would be 
nice result in itself if it didn't take a whole day in place of one 
minute for bash line.)


--

With Best Regards,
Marat Khalili

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

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Qu Wenruo]

On 2017年09月25日 16:04, Qu Wenruo wrote:



On 2017年09月25日 15:52, Hugo Mills wrote:

On Mon, Sep 25, 2017 at 03:46:15PM +0800, Qu Wenruo wrote:



On 2017年09月25日 15:42, Marat Khalili wrote:

On 25/09/17 10:30, Nikolay Borisov wrote:

On 19.09.2017 10:41, Misono, Tomohiro wrote:

"btrfs subvolume create/delete" outputs the message of "Create/Delete
subvolume ..." even when an operation fails.
Since it is confusing, let's outputs the message only when an
operation succeeds.
Please change the verb to past tense, more strongly signaling 
success -

i.e. "Created subvolume"

What about recalling some UNIX standards and returning to NOT
outputting any message when operation succeeds? My scripts are
full of grep -v calls after each btrfs command, and this sucks
(and I don't think I'm alone in this situation).


Isn't the correct way to catch the return value instead of grepping
the output?


    It is, but if, for example, you're using the command in a cron
script which is expected to work, you don't want it producing output
because then you get a mail every time the script runs. So you have to
grep -v on the "success" output to make the successful script silent.


What about redirecting stdout to /dev/null and redirecting stderr to 
mail if return value is not 0?

s/if return value is not 0/if return value is 0/.

The main point is, if btrfs returns 0, then nothing to worry about.
(Unless there is a bug, even in that case keep an eye on stderr should 
be enough to catch that)


Thanks,
Qu
As for expected-to-work case, the stdout doesn't has much meaning and 
return value should be good enough to judge the result.





If it's some command not returning value properly, would you please
report it as a bug so we can fix it.


    It's not the return value that's problematic (although those used
to be a real mess). It's the fact that a successful run of the command
produces noise on stdout, which most commands don't.


Yes, a lot of tried-and-true tools don't output anything for successful 
run, but also a lot of other tools do output something by default, 
especially for complex tools like LVM.


Maybe we can introduce a global --quite option to silent some output.

Thanks,
Qu


    Hugo.

Thanks,
Qu


If you change the message a lot of scripts will have to be
changed, at least make it worth it.

  --

With Best Regards,
Marat Khaliili




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

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Qu Wenruo]

On 2017年09月25日 15:52, Hugo Mills wrote:

On Mon, Sep 25, 2017 at 03:46:15PM +0800, Qu Wenruo wrote:



On 2017年09月25日 15:42, Marat Khalili wrote:

On 25/09/17 10:30, Nikolay Borisov wrote:

On 19.09.2017 10:41, Misono, Tomohiro wrote:

"btrfs subvolume create/delete" outputs the message of "Create/Delete
subvolume ..." even when an operation fails.
Since it is confusing, let's outputs the message only when an
operation succeeds.

Please change the verb to past tense, more strongly signaling success -
i.e. "Created subvolume"

What about recalling some UNIX standards and returning to NOT
outputting any message when operation succeeds? My scripts are
full of grep -v calls after each btrfs command, and this sucks
(and I don't think I'm alone in this situation).


Isn't the correct way to catch the return value instead of grepping
the output?


It is, but if, for example, you're using the command in a cron
script which is expected to work, you don't want it producing output
because then you get a mail every time the script runs. So you have to
grep -v on the "success" output to make the successful script silent.


What about redirecting stdout to /dev/null and redirecting stderr to 
mail if return value is not 0?
As for expected-to-work case, the stdout doesn't has much meaning and 
return value should be good enough to judge the result.





If it's some command not returning value properly, would you please
report it as a bug so we can fix it.


It's not the return value that's problematic (although those used
to be a real mess). It's the fact that a successful run of the command
produces noise on stdout, which most commands don't.


Yes, a lot of tried-and-true tools don't output anything for successful 
run, but also a lot of other tools do output something by default, 
especially for complex tools like LVM.


Maybe we can introduce a global --quite option to silent some output.

Thanks,
Qu


Hugo.
  

Thanks,
Qu


If you change the message a lot of scripts will have to be
changed, at least make it worth it.

  --

With Best Regards,
Marat Khaliili




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

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Hugo Mills]

On Mon, Sep 25, 2017 at 03:46:15PM +0800, Qu Wenruo wrote:
> 
> 
> On 2017年09月25日 15:42, Marat Khalili wrote:
> >On 25/09/17 10:30, Nikolay Borisov wrote:
> >>On 19.09.2017 10:41, Misono, Tomohiro wrote:
> >>>"btrfs subvolume create/delete" outputs the message of "Create/Delete
> >>>subvolume ..." even when an operation fails.
> >>>Since it is confusing, let's outputs the message only when an
> >>>operation succeeds.
> >>Please change the verb to past tense, more strongly signaling success -
> >>i.e. "Created subvolume"
> >What about recalling some UNIX standards and returning to NOT
> >outputting any message when operation succeeds? My scripts are
> >full of grep -v calls after each btrfs command, and this sucks
> >(and I don't think I'm alone in this situation).
> 
> Isn't the correct way to catch the return value instead of grepping
> the output?

   It is, but if, for example, you're using the command in a cron
script which is expected to work, you don't want it producing output
because then you get a mail every time the script runs. So you have to
grep -v on the "success" output to make the successful script silent.

> If it's some command not returning value properly, would you please
> report it as a bug so we can fix it.

   It's not the return value that's problematic (although those used
to be a real mess). It's the fact that a successful run of the command
produces noise on stdout, which most commands don't.

   Hugo.
 
> Thanks,
> Qu
> 
> >If you change the message a lot of scripts will have to be
> >changed, at least make it worth it.
> >
> >  --
> >
> >With Best Regards,
> >Marat Khaliili
> >

-- 
Hugo Mills | If you see something, say nothing and drink to
hugo@... carfax.org.uk | forget
http://carfax.org.uk/  |
PGP: E2AB1DE4  | Welcome to Night Vale


signature.asc
Description: Digital signature

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Qu Wenruo]

On 2017年09月25日 15:42, Marat Khalili wrote:

On 25/09/17 10:30, Nikolay Borisov wrote:

On 19.09.2017 10:41, Misono, Tomohiro wrote:

"btrfs subvolume create/delete" outputs the message of "Create/Delete
subvolume ..." even when an operation fails.
Since it is confusing, let's outputs the message only when an 
operation succeeds.

Please change the verb to past tense, more strongly signaling success -
i.e. "Created subvolume"
What about recalling some UNIX standards and returning to NOT outputting 
any message when operation succeeds? My scripts are full of grep -v 
calls after each btrfs command, and this sucks (and I don't think I'm 
alone in this situation).


Isn't the correct way to catch the return value instead of grepping the 
output?


If it's some command not returning value properly, would you please 
report it as a bug so we can fix it.


Thanks,
Qu

If you change the message a lot of scripts 
will have to be changed, at least make it worth it.


  --

With Best Regards,
Marat Khaliili

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

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

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Hugo Mills]

On Mon, Sep 25, 2017 at 10:42:06AM +0300, Marat Khalili wrote:
> On 25/09/17 10:30, Nikolay Borisov wrote:
> >On 19.09.2017 10:41, Misono, Tomohiro wrote:
> >>"btrfs subvolume create/delete" outputs the message of "Create/Delete
> >>subvolume ..." even when an operation fails.
> >>Since it is confusing, let's outputs the message only when an operation 
> >>succeeds.
> >Please change the verb to past tense, more strongly signaling success -
> >i.e. "Created subvolume"
> What about recalling some UNIX standards and returning to NOT
> outputting any message when operation succeeds? My scripts are full
> of grep -v calls after each btrfs command, and this sucks (and I
> don't think I'm alone in this situation). If you change the message
> a lot of scripts will have to be changed, at least make it worth it.

   Seconded. Make sure the return code reflects the result, and drop
the printed message (or keep it if there's a --verbose flag, maybe).

   Hugo.

-- 
Hugo Mills | If you see something, say nothing and drink to
hugo@... carfax.org.uk | forget
http://carfax.org.uk/  |
PGP: E2AB1DE4  | Welcome to Night Vale


signature.asc
Description: Digital signature

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Marat Khalili]

On 25/09/17 10:30, Nikolay Borisov wrote:

On 19.09.2017 10:41, Misono, Tomohiro wrote:

"btrfs subvolume create/delete" outputs the message of "Create/Delete
subvolume ..." even when an operation fails.
Since it is confusing, let's outputs the message only when an operation 
succeeds.

Please change the verb to past tense, more strongly signaling success -
i.e. "Created subvolume"
What about recalling some UNIX standards and returning to NOT outputting 
any message when operation succeeds? My scripts are full of grep -v 
calls after each btrfs command, and this sucks (and I don't think I'm 
alone in this situation). If you change the message a lot of scripts 
will have to be changed, at least make it worth it.


 --

With Best Regards,
Marat Khaliili

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

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Nikolay Borisov]

On 19.09.2017 10:41, Misono, Tomohiro wrote:
> "btrfs subvolume create/delete" outputs the message of "Create/Delete
> subvolume ..." even when an operation fails.
> Since it is confusing, let's outputs the message only when an operation 
> succeeds.
> 
> Signed-off-by: Tomohiro Misono 
> ---
>  cmds-subvolume.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/cmds-subvolume.c b/cmds-subvolume.c
> index 666f6e0..6d4b0fe 100644
> --- a/cmds-subvolume.c
> +++ b/cmds-subvolume.c
> @@ -189,7 +189,6 @@ static int cmd_subvol_create(int argc, char **argv)
>   if (fddst < 0)
>   goto out;
>  
> - printf("Create subvolume '%s/%s'\n", dstdir, newname);
>   if (inherit) {
>   struct btrfs_ioctl_vol_args_v2  args;
>  
> @@ -213,6 +212,7 @@ static int cmd_subvol_create(int argc, char **argv)
>   error("cannot create subvolume: %s", strerror(errno));
>   goto out;
>   }
> + printf("Create subvolume '%s/%s'\n", dstdir, newname);

Please change the verb to past tense, more strongly signaling success -
i.e. "Created subvolume"

>  
>   retval = 0; /* success */
>  out:
> @@ -337,9 +337,6 @@ again:
>   goto out;
>   }
>  
> - printf("Delete subvolume (%s): '%s/%s'\n",
> - commit_mode == 2 || (commit_mode == 1 && cnt + 1 == argc)
> - ? "commit" : "no-commit", dname, vname);
>   memset(, 0, sizeof(args));
>   strncpy_null(args.name, vname);
>   res = ioctl(fd, BTRFS_IOC_SNAP_DESTROY, );
> @@ -349,6 +346,9 @@ again:
>   ret = 1;
>   goto out;
>   }
> + printf("Delete subvolume (%s): '%s/%s'\n",
> + commit_mode == 2 || (commit_mode == 1 && cnt + 1 == argc)
> + ? "commit" : "no-commit", dname, vname);

Ditto: "Deleted subvolume"

>  
>   if (commit_mode == 1) {
>   res = wait_for_commit(fd);
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] btrfs-progs: subvolume: outputs message only when operation succeeds

[Satoru Takeuchi]

At Tue, 19 Sep 2017 16:41:52 +0900,
Misono, Tomohiro wrote:
> 
> "btrfs subvolume create/delete" outputs the message of "Create/Delete
> subvolume ..." even when an operation fails.
> Since it is confusing, let's outputs the message only when an operation 
> succeeds.
> 
> Signed-off-by: Tomohiro Misono 

Current message as follows is odd as you said. 

```
Create subvolume './test'
ERROR: cannot create subvolume: No such file or directory
```

It's ambiguous for users to know whether creating subvolume succeeded or not.

I tested this patch with injecting error on ioctl() for subvol 
creation/deletion.

Reviewed-by: Satoru Takeuchi 
Tested-by: Satoru Takeuchi 

> ---
>  cmds-subvolume.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/cmds-subvolume.c b/cmds-subvolume.c
> index 666f6e0..6d4b0fe 100644
> --- a/cmds-subvolume.c
> +++ b/cmds-subvolume.c
> @@ -189,7 +189,6 @@ static int cmd_subvol_create(int argc, char **argv)
>   if (fddst < 0)
>   goto out;
>  
> - printf("Create subvolume '%s/%s'\n", dstdir, newname);
>   if (inherit) {
>   struct btrfs_ioctl_vol_args_v2  args;
>  
> @@ -213,6 +212,7 @@ static int cmd_subvol_create(int argc, char **argv)
>   error("cannot create subvolume: %s", strerror(errno));
>   goto out;
>   }
> + printf("Create subvolume '%s/%s'\n", dstdir, newname);
>  
>   retval = 0; /* success */
>  out:
> @@ -337,9 +337,6 @@ again:
>   goto out;
>   }
>  
> - printf("Delete subvolume (%s): '%s/%s'\n",
> - commit_mode == 2 || (commit_mode == 1 && cnt + 1 == argc)
> - ? "commit" : "no-commit", dname, vname);
>   memset(, 0, sizeof(args));
>   strncpy_null(args.name, vname);
>   res = ioctl(fd, BTRFS_IOC_SNAP_DESTROY, );
> @@ -349,6 +346,9 @@ again:
>   ret = 1;
>   goto out;
>   }
> + printf("Delete subvolume (%s): '%s/%s'\n",
> + commit_mode == 2 || (commit_mode == 1 && cnt + 1 == argc)
> + ? "commit" : "no-commit", dname, vname);
>  
>   if (commit_mode == 1) {
>   res = wait_for_commit(fd);
> -- 
> 2.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html