ZFSv28, zfs list behaviour and sysutils/freebsd-snapshot

Graham Todd gtodd at bellanet.org
Mon Apr 4 19:02:09 UTC 2011

On 03/14/2011 05:41, J. Hellenthal wrote:
> On Mon, 14 Mar 2011 04:30, mikael.urankar@ wrote:
>> On Mon 14 March 2011 at 02:44:16AM -0400, J. Hellenthal wrote:
>>> Hash: SHA1
>>> On Thu, 10 Mar 2011 08:17, mikael.urankar@ wrote:
>>>> Hi,
>>>> I'm using sysutils/freebsd-snapshot to make periodic ZFS backup snapshot
>>>> and this soft is broken since the upgrade of my pool to ZFSv28.
>>>> After some debugging it appears that "zfs list" behaviour has changed
>>>> with ZFSv28, and since freebsd-snapshot relies on "zfs list" to retrieve
>>>> the "ZFS file system name" from the "mountpoint name" the soft doesn't
>>>> work anymore.
>>>> output of "zfs list" on a 8.2R amd64 (ZFSv15) :
>>>> zfs list /home/murankar
>>>> tank/home/murankar 1.47M 1.59T 1.47M /home/murankar
>>>> zfs list tank/home/murankar
>>>> tank/home/murankar 1.47M 1.59T 1.47M /home/murankar
>>>> on a 9-Current amd64 I've got no output for "zfs list /home/murankar"
>>>> and a exit code of 1
>>>> the output of "zfs list tank/home/murankar" is correct :
>>>> tank/home/murankar 6,56G 286G 6,55G /home/murankar
>>> Looking at the output here I am hoping that this is not hand typed! the
>>> character ',' appears in this output which might fool a script into doing
>>> other things if it has not been avoided in the first place.
>> This is not hand typed and depends on the locale in use :
>> zfs list tank/home/murankar
>> tank/home/murankar 6,65G 286G 6,58G /home/murankar
>> setenv LANG en_US.UTF8
>> zfs list tank/home/murankar
>> tank/home/murankar 6.65G 286G 6.58G /home/murankar
>> freebsd-snapshot set LC_ALL and LANG to C
>>> If you have upgraded that machine to 9-CURRENT and have
>>> sysutils/zfsnap installed I would recommend deleting any snapshots
>>> that you have before it runs the snapshot scripts. This assumes that the
>>> snapshot script might have changed since you upgraded it and that the
>>> snapshot names are different. Better to be on the sane side.
>>> See UPDATING/20100929 for reference.
>> I've deleted all old snapshots before running the snapshot scripts, but
>> to not avail.
>>> # Correct syntax:
>>> zfs list pool/dataset1/dataset2
>>> # Incorrect syntax: ( I hope you were hand typing that and missed... )
>>> zfs list /dataset1/dataset2
>> In fact I was only doing by "hand" what freebsd-snapshot is doing.
>> See op_make() from /usr/local/sbin/snapshot (near line 285) :
>> # operate on filesystem
>> + echo "XXX zfs list $fs_dir"
>> if [ ".$zfs_enabled" = .yes ] && (zfs list $fs_dir) >/dev/null
>> 2>&1; then
>> /usr/local/sbin/snapshot make -g4 /var:test
>> XXX zfs list /var
>>>> Is it the normal behaviour for ZFSv28 or some kind of regression ?
>>> No its not normal, and some sort of regression possible. Though I usually
>>> take regression as performance issues as in speed.
>>> Also,
>>> pkg-descr
>>> freebsd-snapshot is a set of convenience front-end tools to mount(8)
>>> and mdconfig(8) for the management of UFS2 snapshots. It is
>>> also the under-lying tool used in the periodic snapshot
>>> scheduler periodic-snapshot(8) and the mounting/unmouning
>>> command in the amd(8) map /usr/local/etc/amd.map.snap. It
>>> provides the making, expiring, visiting, mounting and
>>> unmounting of filesystem snapshots.
>>> pkg-descr
>>> zfSnap is simple sh script to make rolling zfs snapshots with cron. Main
>>> advantage of zfSnap is that it's written in %100 pure /bin/sh, doesn't
>>> require any additional software to run, and is simple to use.
>>> zfSnap keeps all information about snapshot in snapshot name. zfs snapshot
>>> names are in form: Time-stamp--TTL where time-stamp is date and time of
>>> snapshot creation and TTL is Time To Live in human readable form.
>>> Did you happen to mix the above two up ? If so then rinse and repeat.
>> Nope, freebsd-snapshot can handle ZFS snapshot and it uses to work fine
>> with ZFSv{14,15}, see the copyright notice :
>> FreeBSD UFS/ZFS Snapshot Management Environment, the pkg-descr file
>> seems outdated.
>> Thanks for your help.
> Since this is s locale dependent script I have added the maintainer to the
> CC so he can adjust it properly upstream.
> A simple ( export LC_ALL=C ) to the top of the script should fix it
> permanently.

Sorry for late response. I do not have access to CURRENT or a ZFSv28 just 
now but there is a patch in the port (files/patch-snapshot) that sets the 
locale to C for compatibility. It's in the install from ports that I use:

egrep -i LC_\|LANG /usr/local/sbin/snapshot

Not sure what the error might come from otherwise. I agree an updated 
description should indicate the ZFS features of freebsd-snapshot. I will 
submit something as a port patch. Maybe:

freebsd-snapshot is a snapshot management tool for UFS2 only, ZFS only, 
and "mixed" systems - one that you can keep on using even as you switch 
file systems and layouts. freebsd-snapshot provides a uniform interface 
for all snapshots and simplifies administration if you have a mix of file 
system types.

Do you have any other suggested changes? Maybe for convenience "snapshot 
list" could indicate whether a snapshot derives from a ZFS or a UFS file 
system without requiring the -v flag? Perhaps better documentation of 
behaviours when a snapshot is ZFS or USF2 based would be helpful. E.g. the 
"mount" "visit" "umount" are sub-commands are either redundant or do 
different things if one is using ZFS or UFS2.  The script could maybe 
catch when umount is used for a snapshot that does exist but does not 
require umount'ing and does not use md(4) (i.e. ZFS snapshots - currently 
I think that case emits a misleading error message? I can't recall exactly 
but I remember noticing this once). Mostly quite small changes are all I 
can think off. Maybe tarsnap integration ? ;-D

Of course a lot of functionality is getting "built-in" to zfs and related 
zfs only scripts, and I am not sure how much more development or what 
direction Ralf has planned for his freebsd-snapshot tool. My impression 
is that *lots* of people are still using UFS2. If SUJ becomes the default 
for 9.0, UFS2 could soldier on for a long time - even on TB+ file systems 
- so this simple but excellent tool will remain very useful.



More information about the freebsd-ports mailing list