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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
