ctldir (.zfs) : some progress
15 views
Skip to first unread message
Emmanuel Anne
Nov 20, 2009, 7:50:12 AM11/20/09
to zfs-...@googlegroups.com
I have been busy fighting this thing lately, and I finally made some progress.
The short version is :
- the crashes and duplications of entreis are fixed
- we now use z_ctldir as we were supposed to
- automatic creation and mounting (readonly) of the clones of the snapshots when a lookup is made on the directory of the snapshot.
- automatic destruction of the temporary clone when the parent is unmounted
This becomes usable and interesting I would say.
Also I changed the options so that normal users can browse the snapshots (normally the rename/mkdir operations check if they have the permissions to change snapshots, so normal users will probably be denied these functions).
There are still some improvements to be made, like using direct functions instead of calling the external zfs program for the clone creation/destruction and for the renames, I'll do this later.
The temporary clones are created with this name : datasetname/snap_snapshotname, they are supposed to be temporary, that's why they are mounted readonly,.
Any idea to improve the mount method is welcome.
If some users are bold enough to test this, it would be useful for me, everything is in the ctldir branch.
Last notice : the mounting of the clones is done on the lookup call because it's easier to correctly reply to a lookup before the snapshot is mounted than to do the same thing for a readdir inside the root directory of the snapshot. But when you first look in .zfs/snapshot, the ls tends to call lookup for everything inside, which mounts every snapshot, so maybe it will have to be improved later !
--
zfs-fuse git repository : http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
The short version is :
- the crashes and duplications of entreis are fixed
- we now use z_ctldir as we were supposed to
- automatic creation and mounting (readonly) of the clones of the snapshots when a lookup is made on the directory of the snapshot.
- automatic destruction of the temporary clone when the parent is unmounted
This becomes usable and interesting I would say.
Also I changed the options so that normal users can browse the snapshots (normally the rename/mkdir operations check if they have the permissions to change snapshots, so normal users will probably be denied these functions).
There are still some improvements to be made, like using direct functions instead of calling the external zfs program for the clone creation/destruction and for the renames, I'll do this later.
The temporary clones are created with this name : datasetname/snap_snapshotname, they are supposed to be temporary, that's why they are mounted readonly,.
Any idea to improve the mount method is welcome.
If some users are bold enough to test this, it would be useful for me, everything is in the ctldir branch.
Last notice : the mounting of the clones is done on the lookup call because it's easier to correctly reply to a lookup before the snapshot is mounted than to do the same thing for a readdir inside the root directory of the snapshot. But when you first look in .zfs/snapshot, the ls tends to call lookup for everything inside, which mounts every snapshot, so maybe it will have to be improved later !
--
zfs-fuse git repository : http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
sgheeren
Jan 4, 2010, 3:14:43 PM1/4/10
to zfs-...@googlegroups.com
If some users are bold enough to test this, it would be useful for me, everything is in the ctldir branch.
I am !
It works. Sort of!
Attached is a demo session (run with 'scriptreplay ctldir.timings ctldir', sitback and enjoy. Read the comments for my thoughts/emphasis).
Also attached: tail -f /var/log/messages > ctldir.log (nothing special).
Notes: using zpool import -R /prefix will mess up the mount points generated for the snapshots. The snapdir is (correctly) in
/prefix/pool/fs/.zfs
But then
# cd /prefix/pool/fs/.zfs/snapshots
# ls
one two three
# cd one
Err: not a directory
# ls one
Err: not a directory
The problem is a misplaced mountpoint, _this_ works:
# ls /prefix/prefix/fs/.zfs/snaphots/one
payload.txt
You can see the /prefix applied twice. It didn't seem to break the actual behaviour aside from the wrong path
We might use a fstype id for the snapdir like fuse#zfssnapdir
The clones are not, in fact, readonly at my place. This may have to do with the -R /prefix usage? This would lead to unhappy surprise, since the automatic clones get auto-zapped on unmount.
PS. Strike that. The output of 'mount' suggests it is (rw) but in fact it is not. /confusing/
zfs umount -a results in huge list of 'dataset busy' errors. Repeating several times clears up part of the mess.
zfs umount -a also gives some errors for .zfs dirs: 'dataset not found'; I figure this is a bookkeeping mistake (these mountpoints are zfs-fuse specific, and should not be kept in ZFS list of mounted datasets?).
finally, zfs umount -a did crash the second time I tested this (with a script session running, see attached).
zfs umount -a _does_ succeed when given plenty time. Apparently these tasks get scheduled in the daemon and take long-ish to complete.
Also notable: using something like find /poolroot will bring down most normal-spec servers, especially with a lot of snapshots. There should probably be something against that. (Hiding the snapdir could be it :))
In my demo session I quickly got 144 mounted _clones_ for only 46 snapshots and 18 filesystems. I didn't check the math, I just measured the numbers. For reference:
Greate progress all in all,
Cheers,
Seth
It works. Sort of!
Attached is a demo session (run with 'scriptreplay ctldir.timings ctldir', sitback and enjoy. Read the comments for my thoughts/emphasis).
Also attached: tail -f /var/log/messages > ctldir.log (nothing special).
Notes: using zpool import -R /prefix will mess up the mount points generated for the snapshots. The snapdir is (correctly) in
/prefix/pool/fs/.zfs
But then
# cd /prefix/pool/fs/.zfs/snapshots
# ls
one two three
# cd one
Err: not a directory
# ls one
Err: not a directory
The problem is a misplaced mountpoint, _this_ works:
# ls /prefix/prefix/fs/.zfs/snaphots/one
payload.txt
You can see the /prefix applied twice. It didn't seem to break the actual behaviour aside from the wrong path
We might use a fstype id for the snapdir like fuse#zfssnapdir
The clones are not, in fact, readonly at my place. This may have to do with the -R /prefix usage? This would lead to unhappy surprise, since the automatic clones get auto-zapped on unmount.
PS. Strike that. The output of 'mount' suggests it is (rw) but in fact it is not. /confusing/
zfs umount -a results in huge list of 'dataset busy' errors. Repeating several times clears up part of the mess.
zfs umount -a also gives some errors for .zfs dirs: 'dataset not found'; I figure this is a bookkeeping mistake (these mountpoints are zfs-fuse specific, and should not be kept in ZFS list of mounted datasets?).
finally, zfs umount -a did crash the second time I tested this (with a script session running, see attached).
zfs umount -a _does_ succeed when given plenty time. Apparently these tasks get scheduled in the daemon and take long-ish to complete.
Also notable: using something like find /poolroot will bring down most normal-spec servers, especially with a lot of snapshots. There should probably be something against that. (Hiding the snapdir could be it :))
In my demo session I quickly got 144 mounted _clones_ for only 46 snapshots and 18 filesystems. I didn't check the math, I just measured the numbers. For reference:
Thanks for the work. It is pretty thrilling to have the snapshots appear out of nowhere with zero effort. This would _really_ win some users for zfs-fuse. I'm doing auto-snapshots for some of my users ('clients') but they don't /appreciate/ it well atm. It's just that they have no way of knowing where the snapshots are (they sure as hell don't drop to the CLI !).root@karmic:~# zfs list -H | tee >(wc -l)
desktop 18,2G 10,6G 26K /MUBI/zfs
desktop/PersoonlijkeBestanden 13,0G 10,6G 206M /MUBI/zfs/PersoonlijkeBestanden
desktop/PersoonlijkeBestanden/BUDGETTEER 30,1M 10,6G 30,0M /MUBI/zfs/PersoonlijkeBestanden/BUDGETTEER
desktop/PersoonlijkeBestanden/Belastingdienst 34,8M 10,6G 34,8M /MUBI/zfs/PersoonlijkeBestanden/Belastingdienst
desktop/PersoonlijkeBestanden/Email 420M 10,6G 420M /MUBI/zfs/PersoonlijkeBestanden/Email
desktop/PersoonlijkeBestanden/FORMULIEREN 573K 10,6G 541K /MUBI/zfs/PersoonlijkeBestanden/FORMULIEREN
desktop/PersoonlijkeBestanden/KLANTBESTAND 145M 10,6G 145M /MUBI/zfs/PersoonlijkeBestanden/KLANTBESTAND
desktop/PersoonlijkeBestanden/Mubi 2,39G 10,6G 2,39G /MUBI/zfs/PersoonlijkeBestanden/Mubi
desktop/PersoonlijkeBestanden/MyPictures 7,90G 10,6G 7,90G /MUBI/zfs/PersoonlijkeBestanden/MyPictures
desktop/PersoonlijkeBestanden/OutlookMail 50,5K 10,6G 50,5K /MUBI/zfs/PersoonlijkeBestanden/OutlookMail
desktop/PersoonlijkeBestanden/VTLBBerekeningen 20K 10,6G 20K /MUBI/zfs/PersoonlijkeBestanden/VTLBBerekeningen
desktop/PersoonlijkeBestanden/_oud_en_problematisch 1,84G 10,6G 1,84G /MUBI/zfs/PersoonlijkeBestanden/_oud_en_problematisch
desktop/PersoonlijkeBestanden/boekhoudingen 89,4M 10,6G 88,3M /MUBI/zfs/PersoonlijkeBestanden/boekhoudingen
desktop/home 5,15G 10,6G 31,5K /MUBI/home
desktop/home/marlies 2,19G 10,6G 1,15G /MUBI/home/marlies
desktop/home/marlies/.wine 179M 10,6G 174M /MUBI/home/marlies/.wine
desktop/home/marlies/Photos 675M 10,6G 675M /MUBI/home/marlies/Photos
desktop/home/sehe 170M 10,6G 169M /MUBI/home/sehe
18
sehe@karmic:~/custom/ZFS/src$ zfs list -Ht snapshot | cut -f1 | cut -d@ -f2 | sort -u | tee >(wc -l)
boot0101-1106
boot0101-1443
boot0101-1601
boot1230-0111
boot1230-1530
boot1231-1421
boot1231-2105
cron1230-0130
cron1230-1630
cron1230-1730
cron1230-1830
cron1230-1930
cron1230-2030
cron1230-2130
cron1231-1430
daily0101-0751
hourly0101-0017
hourly0101-0117
hourly0101-0217
hourly0101-0317
hourly0101-0417
hourly0101-0517
hourly0101-0617
hourly0101-0717
hourly0101-0817
hourly0101-0917
hourly0101-1017
hourly0101-1117
hourly0101-1617
hourly0101-1717
hourly0101-1817
hourly0101-1917
hourly0101-2017
hourly0101-2117
hourly0101-2217
hourly0101-2317
hourly0102-0017
hourly1231-1817
hourly1231-1917
hourly1231-2017
hourly1231-2117
hourly1231-2217
hourly1231-2317
oops
wip
zfssend
Greate progress all in all,
Cheers,
Seth
Emmanuel Anne wrote:
I have been busy fighting this thing lately, and I finally made some progress.
The short version is :
- the crashes and duplications of entreis are fixed
- we now use z_ctldir as we were supposed to
- automatic creation and mounting (readonly) of the clones of the snapshots when a lookup is made on the directory of the snapshot.
- automatic destruction of the temporary clone when the parent is unmounted
This becomes usable and interesting I would say.
Also I changed the options so that normal users can browse the snapshots (normally the rename/mkdir operations check if they have the permissions to change snapshots, so normal users will probably be denied these functions).
There are still some improvements to be made, like using direct functions instead of calling the external zfs program for the clone creation/destruction and for the renames, I'll do this later.
The temporary clones are created with this name : datasetname/snap_snapshotname, they are supposed to be temporary, that's why they are mounted readonly,.
Any idea to improve the mount method is welcome.
Last notice : the mounting of the clones is done on the lookup call because it's easier to correctly reply to a lookup before the snapshot is mounted than to do the same thing for a readdir inside the root directory of the snapshot. But when you first look in .zfs/snapshot, the ls tends to call lookup for everything inside, which mounts every snapshot, so maybe it will have to be improved later !
--
zfs-fuse git repository : http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To post to this group, send email to zfs-...@googlegroups.com
To unsubscribe from this group, send email to zfs-fuse+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/zfs-fuse?hl=en
-~----------~----~----~----~------~----~------~--~---
Reply all
Reply to author
Forward
0 new messages