zfs discuss - Feb 2007 - Managing ZFS - perspective from the intended users

In continuation of another thread, I feel the need to address this topic
urgently:
Despite of the great and enormous potential of ZFS and its advanced
architecture, in the end success is measured in use and user acceptance.
One of the promises is (was) a high-level interface. "No more
''format''". As of today, ZFS has done away with
''format'', but introduced a large number of additional,
cumbersome and ambiguous options.
Not that there was anything wrong with options and choice; but it seems to have
forgotten the user, the client, with all its overwhelming technology and
philosophy. The latter is important, since - though its philosophy permits many
of its features - the end user couldn''t bother less. The end user
expects a file system simply to work, without interference. End user, though, is
also the system administrator; be it the home hobbyist or the professional.
My suggestion is to look into the latter; and mainly into the practical
requirements of the latter. His needs should be the focus.

All in all, being the project leader, [b]who I am not[/b], I''d consider
three levels:
 - the real technology, code, concept, bits and Bytes
 - the ''handles'' for these technological details (i.e.
commands and options)
 - the outer shell of the system, the interface to solve the users''
needs
I am sure, we can agree on the relevancy of the latter; and more so that the
system must present itself in a manner that helps the users to command all
practical requirements in a high-level, consistent and logical manner. Relevant
here: In a manner that does not at all require the user to know or understand
technical details.

It is my impression, that there has so far been a lack of activities to list the
needs of the potential user and address these in a high-level syntax. It is
suggested to do this as soon as possible to know the ''outer
shell'' of the system. It will need the input of a representative sample
in order to know what the different tasks holders [b]expect[/b] from a file
system. Neither coders nor file system experts should base their tasks on
assumptions here. Especially items like RAID, Backup, Install and Repair need to
be specified.

To give an [b]example[/b]: As system administrator, I need a simply and
straightforward backup utility to replace my venerable
''dump/restore''. This utility must work independent of current
mount status and backup either a mount point or file system to another mount
point or file system.
My personal preference would be a command like
backup [-f] drive|volume drive|volume
When I type ''backup myvol /dev/dsk/c1d1s0'' any detail like
activity check should be done in the background. The only feedback desired would
be, if
 - the target is already in use [contains data]
 - the target is too small to take all data

Similarly, high-level procedural commands might be desired for 
 - adding a filesystem (drive) to a volume [Example: ''add drive
volume'']
 - mirroring a drive|volume [Example: ''mirror volume drive'']
 - break mirror [Example: ''break mirror volume drive'']
The intention here is not to restrict the possible options; choice is always
good. The intention is to offer an intuitive syntax that permits all basic
operations, including the definition of RAID volumes, essentially as no-brainer
one-liners. And reserve ''exotic'' commands and options and
additional parameters to special cases and expert use.
 
 
This message posted from opensolaris.org

Uwe Dippel wrote:
> It is my impression, that there has so far been a lack of activities 
> to list the needs of the potential user and address these in a 
> high-level syntax. ...
> Especially items like RAID, Backup, Install and Repair need to be 
> specified.
ZFS was designed from day 1 to be easy to use.  Administrators should be
able to simply express their intent.  However, ZFS needs to be flexible
and powerful enough so that the intents of the most demanding
administrators (our customers) *can* be expressed.  For example,
glossing over things like redundancy/RAID, or the space accounting 
associated with snapshots, would not be acceptable.

In order to support a more powerful and flexible model, sometimes old
concepts (eg. volume management) must be replaced with new concepts (eg.
pooled storage).

That said, Sun is also working on simple appliances for targeted use
cases, which limit the ways you can interact with the system (including 
ZFS) in order to make it easier to use.  Stay tuned for more information 
on this in the coming months.
> To give an [b]example[/b]: As system administrator, I need a simply 
> and straightforward backup utility to replace my venerable 
> ''dump/restore''. This utility must work independent of
current mount
> status and backup either a mount point or file system to another 
> mount point or file system. My personal preference would be a command
>  like backup [-f] drive|volume drive|volume When I type ''backup
myvol
>  /dev/dsk/c1d1s0'' any detail like activity check should be done in
> the background.
Your use case makes a number of assumptions that we didn''t want to make
for the general case of ''zfs send'' (eg. that the stream will
be sent to
and stored on a raw device on the same machine as the zpool). However, 
our infrastructure allows us to provide the type of simple, limited-use 
functionality you are requesting.  We appreciate your suggestion and we 
will consider it.  That said, we have limited resources and we need to 
evaluate what will be most useful to the most customers. We must learn 
to walk before we can run.
> Similarly, high-level procedural commands might be desired for - 
> adding a filesystem (drive) to a volume [Example: ''add drive
volume'']
>  - mirroring a drive|volume [Example: ''mirror volume
drive''] - break
> mirror [Example: ''break mirror volume drive''] The
intention here is
> not to restrict the possible options; choice is always good. The 
> intention is to offer an intuitive syntax that permits all basic 
> operations, including the definition of RAID volumes, essentially as 
> no-brainer one-liners. And reserve ''exotic'' commands and
options and
> additional parameters to special cases and expert use.
I believe that all of these tasks are already straightforward one-liners 
(at least, once you have grasped the "pooled storage" concept, as 
explained in the first few paragraphs of the zpool(1m) and zfs(1m) 
manpages):

add a fs to a pool:
# zfs create pool/filesystem
mirror an existing single-disk pool:
# zpool attach pool existing-device new-device
un-mirror a single-disk pool:
# zpool detach pool device
define a raid pool:
# zpool create poolname raidz device1 device2 device3 device4 device5

--matt

Matt,

thanks for some examples and your understanding.
While I am still quarreling to get a pool mounted,

I still find some unexpected (at least in my legacy terms) behaviour:

% zfs mount pool /export/home
is a clear intention. Maybe too much of legacy ?

% zpool import
" .... can be imported using name or id"
In case of duplicate name (e.g. ''home''), zfs does not accept
the usually known location (c1d2p3), even printed next to the name; no, you have
to read and remember 19 arbitrary digits. Silly.

% zpool import
shows all possible imports

% zpool export
fails. For reasons of consistency, it needed to show all the pools associated
that can be exported

% zpool import new home
it should not matter that much, where you place an ''-f''. It
does, though.

% zpool list
should show a mount state / point, for simplicity
 
 
This message posted from opensolaris.org