linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: TARUISI Hiroaki <taruishi.hiroak@jp.fujitsu.com>
To: kreijack@gmail.com
Cc: linux-btrfs@vger.kernel.org, davidnicol@gmail.com,
	chris.mason@oracle.com
Subject: Re: [RFC] Move all btrfs command to only one command
Date: Fri, 22 Jan 2010 09:02:00 +0900	[thread overview]
Message-ID: <4B58EAF8.3060102@jp.fujitsu.com> (raw)
In-Reply-To: <201001212029.26681.kreijack@libero.it>

Hi Goffredo,

It sounds good for me though detailed points need more discussion.
btrfs-progs seems unkind for operator as you mentioned, and many
features will be implemented to btrfsctl from now, it's good that
we arrange and unify btrfs-progs now.

As for me, plain keywords(delete,defrag...) as commands are welcome.

Regards,
taruisi

(2010/01/22 4:29), Goffredo Baroncelli wrote:
> Hi all
> 
> this RFC is about unify all btrfs command (btrfsctl, btrfs-show, btrfs-tune.. 
> ) in only one called "btrfs" (or whatever we want).
> 
> Today "btrfsctl" needs a "bit" of care because
>   * the help is basically wrong [1]
>   * the return codes are incoherent [2]
>   * the syntax of the command are very ugly (a lot of people complained 
>     about the subvolumes/snapshot creation, because they aren't very clear)
>     [3]
>   * the code is a mess (in the main there is a useless for(); there a lot
>     of 'if' because sometime the last argument is the target of ioctl,
>     sometime no..) [4]
>   * The checks of the number of argument are incorrect [5]
> 
> I think that is better to rewrite from scratch a new command instead of 
> patching the old one. So we don't care about the backward compatibility.
> 
> Other filesystem (hammer, tux3, zfs) have only one command for management 
> purpose. Instead we have btrfsctl (which has a lot of different
> function) and btrfs-show, btrfs-tune, btrfs-volume which have few functions.
> 
> There are patches which address [6] some of the previous issues, 
> but these are not integrated (because the developers are busy on other 
> issues). To me rewriting from scratch seems a fast path for solving these 
> issues.
> 
> I made a prototype (see attached file) in bash of what "btrfs" should be. The 
> major different from btrfsctl are:
> - I talk about clone and not snapshot
> - If a sub-volume is required (for example for the cloning), the program check 
> that the argument is a root of the subvolume and not a subdirectory
> - Creating a sub-volume requires only one argument 
> 
> Below some examples:
> 
> $ btrfs                         
> Usage:                                              
>         btrfs clone|-c <source> [<dest>/]<name>     
>                 Clone the subvolume <source> with the name <name> in the 
> <dest>
>                 directory.                                                     
>         btrfs delete|-d <subvolume>                                            
>                 Delete the subvolume <subvolume>.                              
>         btrfs create|-C [<dest>/]<name>
>                 Create a subvolume in <dest> (or the current directory if not
>                 passed.
>         btrfs defrag|-d <file>|<dir> [<file>|<dir>...]
>                 Defragment a file or a directory.
>         btrfs fssync|-s <path>
>                 Force a fs sync on the filesystem <path>
>         btrfs resize|-r [+/-]<newsize>[gkm]|max <filesystem>
>                 Resize the file system. If 'max' is passed, the filesystem
>                 will occupe all available space on the device.
>         btrfs scan|-S [<device> [<device>..]
>                 Scan all device for or the passed device for a btrfs 
> filesystem.
>         btrfs show|-l <dev>|<label> [<dev>|<label>.. ]
>                 Show the btrfs devices
>         btrfs balance|-b <path>
>                 Balance teh chunk across the device
>         btrfs add|-A <dev> <path>
>                 Add a device to a filesystem
>         btrfs rem|-R <dev> <path>
>                 Remove a device to a filesystem
> 
>         btrfs help|--help|-h
>                 Show the help.
> 
> 
> 
> Comment are welcome
> 
> 
> 
> 
> [1] In the help the -r, -c options seem that don't need any further argument; 
> The -D command seems that accpet only "." as 2nd parameter....
> 
> [2] If something goes wrong btrfsctl returns 1; if the ioctl return 0 the 
> command still returns 1...
> 
> [3] See the email in the mailing list
> 
> [4] If I does
>    btrfsctl -c -d -A -S a .
> what result do you aspect ?
> 
> [5] If I pass more argument than the ones needed no error is showed. -D checks 
> if there is only one argument, when it needs two argument...
> 
> [6] 
> - 10/26/09 - little fixme in btrfsctl.c [PATCH] - From: 
> David Nicol <davidnicol@gmail.com>
> - 12/24/09 - [PATCH] btrfs-progs: check slash in deleting subvolumes. - From: 
> TARUISI 
> - 12/13/09 - [PATCH] Improve the btrfsctl help - From: 
> Goffredo Baroncelli <kreijack@gmail.com>
> 
> 


  reply	other threads:[~2010-01-22  0:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-21 19:29 [RFC] Move all btrfs command to only one command Goffredo Baroncelli
2010-01-22  0:02 ` TARUISI Hiroaki [this message]
2010-01-22  0:11 ` Michael Niederle
2010-01-22  9:33   ` Xavier Nicollet
2010-01-22  8:23 ` Adrian von Bidder
2010-01-24 17:35 ` [RFC] Move all btrfs command to only one command: btrfs.c Goffredo Baroncelli
2010-01-24 18:34   ` Piavlo
2010-02-11 16:33   ` Chris Mason
2010-02-11 18:15     ` Goffredo Baroncelli
2010-02-11 21:20     ` rk
2010-02-11 21:29       ` Goffredo Baroncelli
  -- strict thread matches above, loose matches on Subject: below --
2010-08-19 20:52 [RFC] Move all btrfs command to only one command James Smith
2010-08-20 12:03 ` Goffredo Baroncelli
2010-08-20 12:43   ` Jon Nelson
2010-08-20 14:42     ` Benjamin Griese
2010-08-20 18:56       ` Goffredo Baroncelli
2010-08-20 18:27   ` Josh Berry
2010-08-20 18:34     ` Andreas Philipp
2010-08-20 18:49       ` Josh Berry
2010-08-20 19:00         ` Andreas Philipp
2010-08-20 20:28           ` Josh Berry
2010-08-21  4:51             ` James Smith
2010-08-21  9:37               ` Goffredo Baroncelli
     [not found]                 ` <AANLkTikJd8bDU1Eq22u0+yQ8eBCUn3OXHoE5E7uy+SG=@mail.gmail.com>
     [not found]                   ` <AANLkTi=VpZv26jntJ8mwmxtjnQ5LDOn_MSm6VtEhJ1CB@mail.gmail.com>
2010-08-27  3:38                     ` James Smith
2010-08-20 19:03         ` Goffredo Baroncelli
2010-08-20 12:12 Goffredo Baroncelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B58EAF8.3060102@jp.fujitsu.com \
    --to=taruishi.hiroak@jp.fujitsu.com \
    --cc=chris.mason@oracle.com \
    --cc=davidnicol@gmail.com \
    --cc=kreijack@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).