On Thu, Feb 18, 2010 at 11:59 AM, Goffredo Baroncelli <kreij...@gmail.com> wrote: > On Thursday 18 February 2010, Chris Mason wrote: >> I do like the subcommand method, more details below. >> > > I try to summarise your suggestions. But there are some cases not to clear for > me. > I grouped the commands in three categories: subvolume, devices, and > filesystem. > > > devices scan > devices show > devices balance > devices add > devices remove > > subvolume snapshot > subvolume delete > subvolume create > [subvolume list] > > filesystem resize > [filesystem label] > > ??? defrag > ??? sync > > > > For the first two categories both Chris and Mike agreed; but IMHO there are > some commands that don't fit nor in devices, nor subvolume, like resize (we > resize a filesystem) and label (not available now). >
A btrfs filesystem can span multiple devices. Resize resizes how big of a chunk of one device btrfs uses. This would be used by partitioning programs for instance. zfs uses the term "pool" instead of filesystem to solve this ambiguous use of the term "filesystem" since btrfs and zfs break people's existing definition of the word "filesystem". > I don't know how classify defrag (per file / directory level ?) and sync > (filesystem ?) It turns out that defrag is per file, which seems most cumbersome. Maybe since it will probably eventually work against several types of objects we could have: btrfs defrag file <file> btrfs defrag directory <directory> btrfs defrag subvol <subvol> btrfs defrag pool <pool> > > An option is to consider commands without classification. For examples: > > $ btrfs subvolume create [path/]<subvolname> > $ btrfs sync <path> > $ btrfs defrag <file> Maybe if the btrfs developers are agreeable, we could do this as well: btrfs sync file <file> btrfs sync directory <directory> btrfs sync subvol <subvol> btrfs sync pool <pool> I'm not sure how useful syncing the pool or a directory tree would be, but I'll include it here for further discussion. Mike -- 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
