zfs code - Mar 2009 - Have an idea about ZFS improvements - step to the user. Is it actual?

Hi, I have an idea about improvements of ZFS from the one side and improvements
for of the GUI interface from the other side. Let me describe my idea.
>From the one side we have an ZFS on-th-fly snapshots, and starting from
OpenSolaris 2008.11 we have TimeSlider user feature based on ZFS snaphots. So,
we made a big step to the user.
But from the other side we still have in GUI interface "old"
Move-To-Trash behaviour: this is usual mv command when user delete files on
he''s ZFS partition and copy+delete commands for all other partitions.
So when user''s home is rpool/export/home/username and this user perform
Move-To-Trash operation for some file from, let''s say,
rpool/export/share/allusers, this file actually copied to
rpool/export/home/username (.local folder in user home) and if size of this file
is not to small (for example 1 or 2 Gb) this operation takes a lot of time and a
lot of free disk space of both partitions.
And, o''cos, Move-To-Trash function now available only for users with
GUI access to system, not to shell users.

We we look to the pure user system - Mac OS, we can see that moving to trash of
any file is atomic operation (like snapshots on ZFS) and actually file is always
moved to some .Trash folder on current partition.

An itea is simple and I believe that it''s realization on ZFS side is in
terms of main ZFS idea.
let it be some command like ''zrm'' with syntax equal to
''rm'' syntax, and this command will not remove file, but move
file to .zfs/trash folder (for example with full path and o''cos with
all permissions). And, for example, the new command ''ztrash''
with features for managing this ''trash'' like list of deleted
files, undelete some file, etc. And, o''cos, user interface will use
this two commands when working on ZFS.
What we will have of this:
1. Move-To-Trash will be very fast operation, not depending on file size and
location
2. deleted files in any case will take the same disk space as before deletion
3. Move-To-Trash feature become available to console users, not only to GUI
users
4. we will have some ''out-of-snapshots'' space :) for example
to hide file from snapshot move it to trash, then create the snapshot and after
this - undelete file.

Any comments?
-- 
This message posted from opensolaris.org

Eugene Turkulevich wrote:
> Hi, I have an idea about improvements of ZFS from the one side and
improvements for of the GUI interface from the other side. Let me describe my
idea.
> 
>>From the one side we have an ZFS on-th-fly snapshots, and starting from
OpenSolaris 2008.11 we have TimeSlider user feature based on ZFS snaphots. So,
we made a big step to the user.
> 
> But from the other side we still have in GUI interface "old"
Move-To-Trash behaviour: this is usual mv command when user delete files on
he''s ZFS partition and copy+delete commands for all other partitions.
So when user''s home is rpool/export/home/username and this user perform
Move-To-Trash operation for some file from, let''s say,
rpool/export/share/allusers, this file actually copied to
rpool/export/home/username (.local folder in user home) and if size of this file
is not to small (for example 1 or 2 Gb) this operation takes a lot of time and a
lot of free disk space of both partitions.
> And, o''cos, Move-To-Trash function now available only for users
with GUI access to system, not to shell users.
> 
> We we look to the pure user system - Mac OS, we can see that moving to
trash of any file is atomic operation (like snapshots on ZFS) and actually file
is always moved to some .Trash folder on current partition.
> 
> An itea is simple and I believe that it''s realization on ZFS side
is in terms of main ZFS idea.
> let it be some command like ''zrm'' with syntax equal to
''rm'' syntax, and this command will not remove file, but move
file to .zfs/trash folder (for example with full path and o''cos with
all permissions). And, for example, the new command ''ztrash''
with features for managing this ''trash'' like list of deleted
files, undelete some file, etc. And, o''cos, user interface will use
this two commands when working on ZFS.
> What we will have of this:
> 1. Move-To-Trash will be very fast operation, not depending on file size
and location
> 2. deleted files in any case will take the same disk space as before
deletion
> 3. Move-To-Trash feature become available to console users, not only to GUI
users
> 4. we will have some ''out-of-snapshots'' space :) for
example to hide file from snapshot move it to trash, then create the snapshot
and after this - undelete file.
> 
> Any comments?
I agree that the mac-style GUI behavior would be nice.  You should probably 
take it up with whatever code is implementing the current move-or-copy to 
trash behavior.  Presumably Gnome?  You might want to try asking about this 
over in the Desktop community:

http://opensolaris.org/os/community/desktop/

--matt

Hi niall,

yes, you''re right, when we think in terms of big servers with large
amount of data storages, a lot of users and a lot of network mounts the only one
way to make it work is to use very simple mechanism as you describe: assume that
user have enough free space in home directory and copy all deleted files there.

But! OpenSolaris become available on the usual computers too, now it can be used
on home desktop system or even on notebooks (as I know, Toshiba will sell some
of their notebooks with OpenSolaris preinstalled), so, it''s time to
think about limitations of desktop systems: not a lot of users, usually no
constant mounts, but limited disk space.

For example, my first installation of OpenSolaris was made on 10Gb partition
(for rpool, so this is for entire system and user homes) with 300Gb of storage
for all other stuff (including download location). And my first experience was
deleting of several 1-2Gb files downloaded via Transmission, which was finished
with ''pool usage is more then 80%, all automatic snapshots were
deleted'' (before I stop copying this 15Gb to home located trash folder
with 10Gb for entire partition). I even reported a bug for Transmission, but
together with developer we decide ''same as Nautilus'' and close
it.

BTW, snapshots is not a god idea in this situation too: when user try to reduce
disk space usage, found a 10-20-30Gb of files to be deleted, and even delete it,
the only one way to free disk space is manually delete every snapshot made with
this files.

That''s why I propose to start thinking in terms of usual user, not as
system administrator of server with unlimited disk resources :)
-- 
This message posted from opensolaris.org