> +static struct flags_name snapshot_flags_array[] = {
> + { NEXT3_SNAPFILE_LIST_FL, "S", "on_liSt" },
> + { NEXT3_SNAPFILE_ENABLED_FL, "n", "eNabled" },
> + { NEXT3_SNAPFILE_ACTIVE_FL, "a", "Active" },
> + { NEXT3_SNAPFILE_INUSE_FL, "p", "inuse_by_Previous" },
> + { NEXT3_SNAPFILE_DELETED_FL, "s", "Deleted" },
> + { NEXT3_SNAPFILE_SHRUNK_FL, "h", "sHrunk" },
> + { NEXT3_SNAPFILE_OPEN_FL, "o", "mOunted" },
> + { NEXT3_SNAPFILE_TAGGED_FL, "t", "Tagged" },
> { 0, NULL, NULL }
> };
While clever, I don't think this necessarily makes for a good user interface.
In comparison, flags "l, e, a, i, d, s, m ,t" respectively make much easier to understand/remember name abbreviations.
Cheers, Andreas
--
Andreas Dilger
Lustre Technical Lead
Oracle Corporation Canada Inc.
On Mon, Jun 21, 2010 at 9:17 PM, Andreas Dilger
<[email protected]> wrote:
>> +static struct flags_name snapshot_flags_array[] = {
>> + ? ? { NEXT3_SNAPFILE_LIST_FL, "S", "on_liSt" },
>> + ? ? { NEXT3_SNAPFILE_ENABLED_FL, "n", "eNabled" },
>> + ? ? { NEXT3_SNAPFILE_ACTIVE_FL, "a", "Active" },
>> + ? ? { NEXT3_SNAPFILE_INUSE_FL, "p", "inuse_by_Previous" },
>> + ? ? { NEXT3_SNAPFILE_DELETED_FL, "s", "Deleted" },
>> + ? ? { NEXT3_SNAPFILE_SHRUNK_FL, "h", "sHrunk" },
>> + ? ? { NEXT3_SNAPFILE_OPEN_FL, "o", "mOunted" },
>> + ? ? { NEXT3_SNAPFILE_TAGGED_FL, "t", "Tagged" },
>> ? ? ? { 0, NULL, NULL }
>> ?};
>
> While clever, I don't think this necessarily makes for a good user interface.
> In comparison, flags "l, e, a, i, d, s, m ,t" respectively make much easier to understand/remember name abbreviations.
>
I must show you the beauty of the 'S','n','a','p','s','h','o','t'
flags, because I grew very fond of them.
Here is a list of 4 snapshots for example:
Snapshots list:
id inode attributes disk-usage mtime filename
---------------------------------------------
44 277994 Snap--o- 7.3M Jun 14 16:50 /var/vol/2/.ctera/snapshots/4
43 277993 S--psh-- 12.0K Jun 14 16:50 /var/vol/2/.ctera/snapshots/3
42 277992 ----sh-- 0 Jun 14 16:50 /var/vol/2/.ctera/snapshots/2
41 277991 Sn----o- 1.2M Jun 14 16:50 /var/vol/2/.ctera/snapshots/1
.
The capital S is a graphical representation of the snapshots list chains
(snapshot 2 was removed from the list after all its blocks were merged
into snapshot 1).
Both snapshots 2 and 3 were SHrunk, which is represented by the flag pair 'sh'
(the flag 's' alone represents a temporary transitional state before 'sh').
Both snapshots files 1 and 4 have been Opened by losetup (i.e., mounted).
BTW, Ted has suggested to combine the 'n' and 'o' flags (i.e.,
auto-enable on open).
When the snapshot list is sorted by snapshot id, as the script command
'snapshot status' does,
the 'p' flags graphically points towards a previous enabled snapshot,
which is a dependency of this snapshot
(snapshot 4 and snapshot 3 blocks are accessed by mounted snapshot 1 readers)
So far for lsattr -X flags.
As for chattr -X flags, I intend to eliminate those altogether.
As Ted suggested, controlling the 'n' flag, will no longer be needed,
once auto-enable is implemented.
Instead of controlling the 'S' flag for snapshot take/delete, 'take'
will be invoked automatically on create()
of file in a snapshots directory and 'delete' will be invoked on
attempt to unlink() a snapshot file.
See new API design at:
http://sourceforge.net/apps/mediawiki/next3/index.php?title=User-kernel_API
Amir.
On Tue, Jun 22, 2010 at 11:56 AM, Amir G.
<[email protected]> wrote:
> On Mon, Jun 21, 2010 at 9:17 PM, Andreas Dilger
> <[email protected]> wrote:
>>> +static struct flags_name snapshot_flags_array[] = {
>>> + ? ? { NEXT3_SNAPFILE_LIST_FL, "S", "on_liSt" },
>>> + ? ? { NEXT3_SNAPFILE_ENABLED_FL, "n", "eNabled" },
>>> + ? ? { NEXT3_SNAPFILE_ACTIVE_FL, "a", "Active" },
>>> + ? ? { NEXT3_SNAPFILE_INUSE_FL, "p", "inuse_by_Previous" },
>>> + ? ? { NEXT3_SNAPFILE_DELETED_FL, "s", "Deleted" },
>>> + ? ? { NEXT3_SNAPFILE_SHRUNK_FL, "h", "sHrunk" },
>>> + ? ? { NEXT3_SNAPFILE_OPEN_FL, "o", "mOunted" },
>>> + ? ? { NEXT3_SNAPFILE_TAGGED_FL, "t", "Tagged" },
>>> ? ? ? { 0, NULL, NULL }
>>> ?};
>>
>> While clever, I don't think this necessarily makes for a good user interface.
>> In comparison, flags "l, e, a, i, d, s, m ,t" respectively make much easier to understand/remember name abbreviations.
>>
>
FYI, I've just resent the snapshot control patch.
The 'leaidsmt' flags where added to Andreas's request.
Those are the default flags when lssnap/chsnap (symlinks to
lsattr/chattr) are invoked.
The 'Snapshot' flags are still supported when lssnap/chsnap -X (or
lsattr/chattr -X) are invoked.
here is the usage of chsnap:
# chsnap
Usage: ./misc/chsnap [-+=let] snapshot files...
Usage: ./misc/chsnap -X [-+=Snt] snapshot files...
>
> As for chattr -X flags, I intend to eliminate those altogether.
> As Ted suggested, controlling the 'n' flag, will no longer be needed,
> once auto-enable is implemented.
> Instead of controlling the 'S' flag for snapshot take/delete, 'take'
> will be invoked automatically on create()
> of file in a snapshots directory and 'delete' will be invoked on
> attempt to unlink() a snapshot file.
>
> See new API design at:
> http://sourceforge.net/apps/mediawiki/next3/index.php?title=User-kernel_API
>
I still didn't get around to implementing the new API,
so for now lssnap/chsnap are still using unused bits in the
GETFLAGS/SETFLAGS ioctl
to control/view snapshot status flags.
Amir.