Re: [zfs-discuss] Books on File Systems and File System Programming
Going back a fair way the basics of FS design are in books like the following Chapter 7 and 8 of The Design and Implementation of the 4.4BSD Operating System, Leffler, McKusick, Karels and Quarterman covers the FFS Chapter 6 of The Magic Garden Explained, Goodheart and Cox addresses SYSV FS Newer systems implement things differently but they try not to break the interfaces that these systems established too much. Maurice Castro On 14/08/2009, at 9:02 AM, Louis-Frédéric Feuillette wrote: I saw this question on another mailing list, and I too would like to know. And I have a couple questions of my own. == Paraphrased from other list == Does anyone have any recommendations for books on File Systems and/or File Systems Programming? == end == ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Zfs improvements to compression in Solaris 10?
Prabahar Jeyaram wrote: You seem to be hitting : http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6586537 The fix is available in OpenSolaris build 115 and later not for Solaris 10 yet. Have you got more information on how was it fixed? -- Robert Milkowski http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] new logbias property
Eric Schrock wrote: On 08/11/09 06:03, Darren J Moffat wrote: I thought so too initially, then I changed my mind and I like it the way it is. The reason being is that describing the intent allows changing the implementation and keeping the meaning. It is the intent that matters to the administrator not the implementation. Also worth noting that is the fact that the use of WR_INDIRECT log writes is altered depending on this property. Even in a pool with no dedicated log devices, changing this property can have an effect on overall performance, so it clearly cannot be defined as simply as "use log devices" or not. - Eric That's good to know. Eric, Darren - thanks for clarification - it makes sense :) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] utf8only and normalization properties
On Thu, Aug 13, 2009 at 05:57:57PM -0500, Haudy Kazemi wrote:
> >Therefore, if you need to interoperate with MacOS X then you should
> >enable the normalization feature.
> >
> Thank you for the reply. My goal is to configure the filesystem for the
> lowest common denominator without knowing up front which clients will be
> used. OS X and Win XP are listed because they are commonly used as
> desktop OSes. Ubuntu Linux is a third potential desktop OS.
Right, so set normalization=formD .
> The normalization property documentation says "this property indicates
> whether a file system should perform a unicode normalization of file
> names whenever two file names are compared. File names are always
> stored unmodified, names are normalized as part of any comparison
> process." Where does the file system use filename comparisons and what
> does it use them for? Filename collision checking? Sorting?
The system does filename comparisons when doing lookups
(open("/foo/bar/baz", ...) does at least three such lookups, for
example), and on create (since that involves a lookup).
Yes, this is about collisions. Consider a file named "á" (that's "a"
with an acute accent). There are _two_ possible encodings for that name
in UTF-8. That means that you could have two files in the same
directory and with the same name, though they'd have different names if
you looked at the bytes that make up the names. That would be
confusing, at the very least.
To avoid such collisions you can enable normalization.
You can find more here:
http://blogs.sun.com/nico/entry/filesystem_i18n
> Is it used for any other operation, say when returning a filename to an
> application? Would applications reading/writing files to a ZFS
No, directory listings always return the filename used when the file
name was created, without any normalization.
> filesystem ever notice the difference in normalization settings as long
> as they produce filenames that do not conflict with existing names or
> create invalid UTF8? The documentation says filenames are stored
> unmodified, which sounds like things should be transparent to applications.
Applications shouldn't notice normalization being enabled. The only
reasons to disable normalization are: a) you don't want to force the use
of UTF-8, or b) you consistently use a single normalization form and you
don't want to pay a penalty for normalizing on lookup.
(b) is probably not a problem -- the normalization code is fast if you
use all US-ASCII strings, and it's linear with the number of non-ASCII,
Unicode codepoints in file names. But I don't have performance numbers
to share. I think that normalization should be enabled by default if
you enable utf8only, and utf8only should probably be enabled by default
in Solaris, but that's just my personal opinion.
> (In regard to filename collision checking, if non-normalized unmodified
> filenames are always stored on disk, and they don't conflict in
> non-normalized form, what would the point be of normalizing the
> filenames for a comparison? To verify there isn't conflict in
> normalized forms, and if there is no conflict with an existing file to
> allow the filename to be written unmodified?)
Yes.
> The ZFS documentation doesn't list the valid values for the
> normalization property other than 'none. From your reply and from the
The zfs(1M) manpage lists them:
normalization = none | formD | formKCf
That's not all existing Unicode normalization forms, no. The reason for
this is that we only normalize on lookup (the file names returned by
readdir are not normalized), and for that the forms C and D are
semantically equivalent, but K and non-K forms are not semantically
equivalent, so we need one K form and one non-K form. NFD is faster
than NFC, but the K forms require a trip through form C, so NFKC is
faster than NFKD (at least if I remember correctly). Which means that
NFD and NFKC were sufficient, and there's no reason to ever want NFC or
NFKD.
> suggest they be added to the documentation at
> http://dlc.sun.com/osol/docs/content/ZFSADMIN/gazss.html
Yes, that's a good point.
PS: ZFS directories are hashed. When normalization is enabled, the
hash keys are normalized on create, but the hash contents are not,
so filenames rename unnormalized.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Books on File Systems and File System Programming
I saw this question on another mailing list, and I too would like to know. And I have a couple questions of my own. == Paraphrased from other list == Does anyone have any recommendations for books on File Systems and/or File Systems Programming? == end == I have some texts listed below, but are there books/journals/periodicals that start from the kernel side of open(2), read(2), write(2), etc. and progress to disk transactions? With the advent of ZFS and other transaction based files systems it seems to me that the line between File Systems and Databases are beginning to blur ( If they haven't already been doing so for some time ). Any pointers the likes of "X from here, Y from there, Z from over yonder and squished together like Q" are also welcome. (relevant) Books I have: Understanding the Linux Kernel ( The chapters about ext2 and VFS ) Systems programming in the UNIX envirionment File Structures: An OO approach using C++ Database System concepts (More about SQL and how to implement Joins ) Thanks in advance. -- Louis-Frédéric Feuillette ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] utf8only and normalization properties
Nicolas Williams wrote: On Wed, Aug 12, 2009 at 06:17:44PM -0500, Haudy Kazemi wrote: I'm wondering what are some use cases for ZFS's utf8only and normalization properties. They are off/none by default, and can only be set when the filesystem is created. When should they specifically be enabled and/or disabled? (i.e. Where is using them a really good idea? Where is using them a really bad idea?) These are for interoperability. The world is converging on Unicode for filesystem object naming. If you want to exclude non-Unicode strings then you should set utf8only (some non-Unicode strings in some codesets can look like valid UTF-8 though). But Unicode has multiple canonical and non-canonical ways of representing certain characters (e.g., ´). Solaris and Windows input methods tend to conform to NFKC, so they will interop even if you don't enable the normalization feature. But MacOS X normalizes to NFD. Therefore, if you need to interoperate with MacOS X then you should enable the normalization feature. Thank you for the reply. My goal is to configure the filesystem for the lowest common denominator without knowing up front which clients will be used. OS X and Win XP are listed because they are commonly used as desktop OSes. Ubuntu Linux is a third potential desktop OS. The normalization property documentation says "this property indicates whether a file system should perform a unicode normalization of file names whenever two file names are compared. File names are always stored unmodified, names are normalized as part of any comparison process." Where does the file system use filename comparisons and what does it use them for? Filename collision checking? Sorting? Is it used for any other operation, say when returning a filename to an application? Would applications reading/writing files to a ZFS filesystem ever notice the difference in normalization settings as long as they produce filenames that do not conflict with existing names or create invalid UTF8? The documentation says filenames are stored unmodified, which sounds like things should be transparent to applications. (In regard to filename collision checking, if non-normalized unmodified filenames are always stored on disk, and they don't conflict in non-normalized form, what would the point be of normalizing the filenames for a comparison? To verify there isn't conflict in normalized forms, and if there is no conflict with an existing file to allow the filename to be written unmodified?) Looking forward, starting with Windows XP and OS X 10.5 clients, is there any reason to change the defaults in order to minimize problems? You should definetely enable normalization (see above). It doesn't matter what normalization form you use, but "nfd" runs faster than "nfc". The normalization feature doesn't cost much if you use all US-ASCII file names. And it doesn't cost much if your file names are mostly US-ASCII. Nico The ZFS documentation doesn't list the valid values for the normalization property other than 'none. From your reply and from the the official unicode docs at http://unicode.org/reports/tr15/ and http://unicode.org/faq/normalization.html would it be correct to conclude that none, NFD, NFC, NFKC, and NFKD are the only valid values for the ZFS normalization property? If so, I suggest they be added to the documentation at http://dlc.sun.com/osol/docs/content/ZFSADMIN/gazss.html Thanks, -hk ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] unsetting/resetting ZFS properties
In short, I think an alias for 'zfs inherit' could be added to 'zfs set' to make it more clear to those of us still new to ZFS. Either that, or add some additional pointers in the Properties documentation that the set command can't unset/reset properties. That would to me be confusing it would also complicate the code quite a lot because now the action would be part of the value for a different subcommand. It also won't work at all for some properties, in particular what if you have a hostname called "inherit" that is going to be very confusing for the share* properties. Maybe I'm missing something, but what would a specific example be? I don't see one in the docs that would create a conflict. I see the following valid options for sharesmb at http://docs.sun.com/app/docs/doc/817-2271/gfwqv?l=en&a=view and at http://docs.sun.com/app/docs/doc/817-2271/gfwpk?l=en&a=view: # zfs set sharesmb=off sandbox/fs2 # zfs set sharesmb=on sandbox # zfs set sharesmb=name=myshare sandbox/fs2 The documentation says this in regards to 'name': "A pseudo property /name /is also supported that allows you to replace the dataset name with a specific name. The specific name is then used to replace the prefix dataset in the case of inheritance." I see the following valid options for sharenfs at http://docs.sun.com/app/docs/doc/817-2271/gamnd?l=en&a=view : # zfs set sharenfs=on tank/home # zfs set sharenfs=ro tank/home/tabriz # zfs set sharenfs=off tank/home The documentation says this: The sharenfs property is a comma-separated list of options to pass to the share command. The special value on is an alias for the default share options, which are read/write permissions for anyone. The special value off indicates that the file system is not managed by ZFS and can be shared through traditional means, such as the /etc/dfs/dfstab file. All file systems whose sharenfs property is not off are shared during boot. 'inherited' would be one more special value. If there is an issue here I believe we should first trying and resolve it with documentation changes. Some UI guides say there is room for improvement in the design of a system if it isn't self-evident/self-documenting to reasonably informed people. As this is happening to tech savvy people (assuming that those who are using/trying out OpenSolaris and ZFS are relatively tech savvy), this is particularly evident. I'd have to say that probably most customers I've worked with on zfs have fallen over this one, given up trying to work out how to do it, and had to ask (and the first time it happened, I had to ask too). The obvious things they have tried are generally something along the lines zfs set foobar=inherit[ed] ... There is something unnatural about the 'zfs inherit' command -- it just isn't where that functionality is expected to be, based on the structure of the other commands. This is exactly what happened to me. I had tried: zfs set compression=off tank/home/smith (had the logical result of setting a local property) zfs set compression=default tank/home/smith zfs set compression=inherit tank/home/smith zfs set compression=inherited tank/home/smith None of which did what I wanted (to set the value to default/inherited). The commands 'zfs get' and 'zfs set' felt natural to view/set/edit filesystem properties. Editing the property to go back to the default/inherited setting really feels like something that belongs under 'zfs set', rather than as a top level command. The documentation examples show 'zfs set' as being 'property=value', and 'value' can take on various text or numerical settings depending on which property is being changed. The intuitive setting is to have a 'value' that unsets/resets. The general thought process: "I used 'zfs set' to change the value of the property, now I want to change it back to what it was, so why should I expect to need to use a different top level command? " I'd like the properties documentation to show all the valid range of values for a given property, if practical. If a 'zfs inherit'/'zfs set' alias was created, one of these values would be 'inherit' or 'inherited' or 'default'. On a related note, the documentation (same URL below) for the "normalization" property is missing the list of valid values besides "none". In regards to potential edge/corner(?) case conflicts with the share* properties, the documentation at http://docs.sun.com/app/docs/doc/817-2271/gazss?l=en&a=view says: Under sharenfs: If set to on, the zfs share command is invoked with no options. Otherwise, the zfs share command is invoked with options equivalent to the contents of this property. Under sharesmb: If the property is set to on, the sharemgr command is invoked with no options. Otherwise, the sharemgr command is invoked with options that are equivalent to the contents of this property. This tells me these two properties are already in effect aliases of other commands.
Re: [zfs-discuss] Can ZFS dynamically grow pool sizes? (re: Windows Home Server)
On Wed, Aug 12 at 17:30, Adam Sherman wrote: I believe you will get .5 TB in this example, no? 1.5T, 1.0T and 0.5T in a single RAID-Z is equivalent to three 0.5T drives in a RAID-Z, which gets you two units worth of capacity and one unit of parity, summing to 1.0T usable. -- Eric D. Mudama edmud...@mail.bounceswoosh.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Can ZFS dynamically grow pool sizes? (re: Windows Home Server)
Is it possible to use the zfs copies property and put the disks individually into a pool? That would give you 3TB (1.5 + 1 + .5) usable. http://blogs.sun.com/relling/entry/zfs_copies_and_data_protection States that copies will be spread across disks. But what I don't know (and don't have a test box to figure out) is if losing a disk still kills the whole pool in spite of having multiple copies of the data. I have a sneaking suspicion is the pool would be toast. -Russ > Erik Trimble wrote: > > While the "figure it out for me and make it as big as > you can while still being > safe" magic of drobo is nice for home users, it's > less than ideal for enterprise > users that require performance guarantees. > > It would be nice if somebody created a simple tool > that, fed a set of disks, > computed the configuration required for maximum > usable redundant space. > > -- > Carson > > > > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] unsetting/resetting ZFS properties
On 13.08.09 13:44, Andrey V. Elsukov wrote: Haudy Kazemi wrote: I recently asked myself this question: Is it possible to unset ZFS properties? Or reset one to its default state without looking up what that default state is? I have another question: is it possible to set ZFS properties without inheritance to all descendant datasets? I'll try to describe my situation. I'm FreeBSD user and for example i have following datasets: zroot/usr zroot/usr/home zroot/usr/home/user1 zroot/usr/home/user2 ... zroot/usr/local zroot/usr/src zroot/usr/ports zroot/usr/ports/distfiles zroot/usr/ports/packages After some initial configuration i want to set readonly property to the `zroot/usr` dataset. And there is problem :) And the problem is that you mix two datasets with different intended uses into one hierarchy. You can better do split these two datasets into separate hierarchies but combine them as you want in the filesystem namespace, something like this: zfs create zroot/usr zfs set mountpoint=$USR zfs create -o mountpoint=$USR/home zroot/home zfs create zroot/home/user1 zfs create zroot/home/user2 zfs set readonly=on zroot/usr victor ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Changing GUID
Cyril, Can you please post the code, I will try to update it and get it to compile as I have a customer with the requirement. Thanks, JK -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs receive -o
Hi, One thing I miss in zfs is the ability to override an attribute value in zfs receive - something like the -o option in zfs create. This option would be particularly useful with zfs send -R to make a backup and be sure that the destination won't be mounted zfs send -R f...@snap | ssh myhost zfs receive -d -o canmount=off backup/host or to have compressed backups, because the compression attribute may be sent with the file system and thus is not necessarily inherited zfs send -R f...@snap | ssh myhost zfs receive -d -o canmount=off -o compression=gzip backup/host It is possible to use -u for the mount problem, but it is not absolutely safe until the property is actually changed. An unexpected reboot can put the backup server in maintenance mode because the file system may have the same mountpoint as another one already there. Do I miss something? Would it be possible to have such an option? Regards, Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr PGP.sig Description: Ceci est une signature électronique PGP ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS, ESX ,and NFS. oh my!
On Aug 13, 2009, at 1:37 AM, James Hess wrote: The real benefit of the of using a separate zvol for each vm is the instantaneous cloning of a machine, and the clone will take almost no additional space initially. In our case we build a You don't have to use ZVOL devices to do that. As mentioned by others... zfs create my_pool/group1 zfs create my_pool/group1/vm1 zfs create my_pool/group1/vm2 In this case, 'vm1' and 'vm2' are on separate filesystems, that will show up in 'zfs list', since 'zfs create' was used to make them. But they are still both under the common mount point '/ my_pool/group1' Now, you could zfs snapshot my_pool/group1/v...@snap-1-2009-06-12 zfs clone my_pool/group1/v...@snap-1-2009-06-12 my_pool/group1/ vm3 zfs promote my_pool/group1/vm3 And you would then have your clone, also under the common mount point.. That was my first mistake I made with ZFS over NFS. What you are actually seeing is the mountpoints remotely not the sub- datasets. If you copy something into those mountpoints remotely you are actually sliging it under the mounted dataset and it won't be snapshotted or cloned. ZFS datasets act like separate file systems, so therefore behave as such in concert with NFS and only NFSv4 allows hierarchal exports. -Ross ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] resizing zpools by growing LUN
Hi Darren, took me a while what device is meant by zdb -l... Original size was 20GB After resizing in EVA format -e showed the new correct size: 17. c6t6001438002A5435A0001006Dd0 /scsi_vhci/s...@g6001438002a5435a0001006d Here is the output of zdb -l: zdb -l /dev/dsk/c6t6001438002A5435A0001006Dd0s0 LABEL 0 version=10 name='huhctmppool' state=0 txg=14 pool_guid=8571912358322557497 hostid=2230083084 hostname='huh014' top_guid=3763080418932148585 guid=3763080418932148585 vdev_tree type='disk' id=0 guid=3763080418932148585 path='/dev/dsk/c6t6001438002A5435A0001006Dd0s0' devid='id1,s...@n6001438002a5435a0001006d/a' phys_path='/scsi_vhci/s...@g6001438002a5435a0001006d:a' whole_disk=1 metaslab_array=14 metaslab_shift=27 ashift=9 asize=21461467136 is_log=0 LABEL 1 version=10 name='huhctmppool' state=0 txg=14 pool_guid=8571912358322557497 hostid=2230083084 hostname='huh014' top_guid=3763080418932148585 guid=3763080418932148585 vdev_tree type='disk' id=0 guid=3763080418932148585 path='/dev/dsk/c6t6001438002A5435A0001006Dd0s0' devid='id1,s...@n6001438002a5435a0001006d/a' phys_path='/scsi_vhci/s...@g6001438002a5435a0001006d:a' whole_disk=1 metaslab_array=14 metaslab_shift=27 ashift=9 asize=21461467136 is_log=0 LABEL 2 version=10 name='huhctmppool' state=0 txg=14 pool_guid=8571912358322557497 hostid=2230083084 hostname='huh014' top_guid=3763080418932148585 guid=3763080418932148585 vdev_tree type='disk' id=0 guid=3763080418932148585 path='/dev/dsk/c6t6001438002A5435A0001006Dd0s0' devid='id1,s...@n6001438002a5435a0001006d/a' phys_path='/scsi_vhci/s...@g6001438002a5435a0001006d:a' whole_disk=1 metaslab_array=14 metaslab_shift=27 ashift=9 asize=21461467136 is_log=0 LABEL 3 version=10 name='huhctmppool' state=0 txg=14 pool_guid=8571912358322557497 hostid=2230083084 hostname='huh014' top_guid=3763080418932148585 guid=3763080418932148585 vdev_tree type='disk' id=0 guid=3763080418932148585 path='/dev/dsk/c6t6001438002A5435A0001006Dd0s0' devid='id1,s...@n6001438002a5435a0001006d/a' phys_path='/scsi_vhci/s...@g6001438002a5435a0001006d:a' whole_disk=1 metaslab_array=14 metaslab_shift=27 ashift=9 asize=21461467136 is_log=0 Is that the output you meant ? Sascha -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] the antithesis of zfs
On Thu, Aug 13, 2009 at 12:23 PM, Darren J Moffat wrote: > russell aspinwall wrote: >> >> Are tools necessary to ensure that deleted ZFS pools can not be recovered >> or that deleted filesystems are really deleted? > > dd if=/dev/zero over the disks, or use format(1M) analyze -> purge. > > For just a single filesystem you can get some comfort level by doing: > > zfs destroy tank/mysensitive > dd if=/dev/zero of=/tank/fill bs=128k > rm /tank/fill > If you happen to have compression turned on that won't do anything. You'll have better luck with /dev/urandom. > Not perfect but all we have today for datasets. -- Regards, Cyril ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] the antithesis of zfs
Thanks for clearing up the issue -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] unsetting/resetting ZFS properties
Haudy Kazemi wrote: I recently asked myself this question: Is it possible to unset ZFS properties? Or reset one to its default state without looking up what that default state is? I have another question: is it possible to set ZFS properties without inheritance to all descendant datasets? I'll try to describe my situation. I'm FreeBSD user and for example i have following datasets: zroot/usr zroot/usr/home zroot/usr/home/user1 zroot/usr/home/user2 ... zroot/usr/local zroot/usr/src zroot/usr/ports zroot/usr/ports/distfiles zroot/usr/ports/packages After some initial configuration i want to set readonly property to the `zroot/usr` dataset. And there is problem :) In this situation it will be very useful to have ability to set properties without inheritance. For example: # zfs set -R readonly=on zroot/usr and readonly property will be set only to zroot/usr, but not to all descendants. Or maybe this functional is already implemented? -- WBR, Andrey V. Elsukov ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] unsetting/resetting ZFS properties
Darren J Moffat wrote: Haudy Kazemi wrote: You run: zfs set compression=off tank/home/smith but that doesn't unset the compression setting for filesystem 'smith', it just overrides the inheritance of compression=on (as expected). So how to unset/reset? zfs inherit compression tank/home/smith * In short, I think an alias for 'zfs inherit' could be added to 'zfs set' to make it more clear to those of us still new to ZFS. Either that, or add some additional pointers in the Properties documentation that the set command can't unset/reset properties. That would to me be confusing it would also complicate the code quite a lot because now the action would be part of the value for a different subcommand. It also won't work at all for some properties, in particular what if you have a hostname called "inherit" that is going to be very confusing for the share* properties. If there is an issue here I believe we should first trying and resolve it with documentation changes. I'd have to say that probably most customers I've worked with on zfs have fallen over this one, given up trying to work out how to do it, and had to ask (and the first time it happened, I had to ask too). The obvious things they have tried are generally something along the lines zfs set foobar=inherit[ed] ... There is something unnatural about the 'zfs inherit' command -- it just isn't where that functionality is expected to be, based on the structure of the other commands. -- Andrew ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] the antithesis of zfs
russell aspinwall wrote: Are tools necessary to ensure that deleted ZFS pools can not be recovered or that deleted filesystems are really deleted? dd if=/dev/zero over the disks, or use format(1M) analyze -> purge. For just a single filesystem you can get some comfort level by doing: zfs destroy tank/mysensitive dd if=/dev/zero of=/tank/fill bs=128k rm /tank/fill Not perfect but all we have today for datasets. If the current delete commands do offer some level of data recovery, > is worth offering a destroy command which deletes and ensures no > means of recovery other than a backup? If you want that level of destruction the accepted best practice is now to use encryption and "forget" your key. This is accepted by many organisations that follow NIST guidelines on data security and key management. Once I'm finished delivering encryption and the BP rewrite project integrates I hope to have time to look at a "erase behind" capability, this would be a per dataset property (or maybe even a per file attribute). -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] unsetting/resetting ZFS properties
Haudy Kazemi wrote: Hello, I recently asked myself this question: Is it possible to unset ZFS properties? Or reset one to its default state without looking up what that default state is? I believe the answer is yes, via the zfs inherit command (I haven't verified yet, but I think a case could be made to add functionality to the zfs set command...or the documentation...to make this clearer.) An example: You have a pool named tank. You have created a filesystem called 'home' and it has a child filesystem called 'smith'. You run: zfs set compression=on tank/home which turns on compression on the 'home' filesystem (it is a local property) and on the 'smith' filesystem (as an inherited property). (You inspect the properties with 'zfs get'.) You then run: zfs set compression=on tank/home/smith which makes compression on the 'smith' filesystem also be a local property. At this point you decide you would rather that the compression property for filesystem 'smith' be inherited after all, not be a local property anymore. You run: zfs set compression=off tank/home/smith but that doesn't unset the compression setting for filesystem 'smith', it just overrides the inheritance of compression=on (as expected). So how to unset/reset? zfs inherit compression tank/home/smith * In short, I think an alias for 'zfs inherit' could be added to 'zfs set' to make it more clear to those of us still new to ZFS. Either that, or add some additional pointers in the Properties documentation that the set command can't unset/reset properties. That would to me be confusing it would also complicate the code quite a lot because now the action would be part of the value for a different subcommand. It also won't work at all for some properties, in particular what if you have a hostname called "inherit" that is going to be very confusing for the share* properties. If there is an issue here I believe we should first trying and resolve it with documentation changes. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] the antithesis of zfs
Are tools necessary to ensure that deleted ZFS pools can not be recovered or that deleted filesystems are really deleted? If the current delete commands do offer some level of data recovery, is worth offering a destroy command which deletes and ensures no means of recovery other than a backup? -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
