Following up on earlier mail, here''s a proposal for create-time
properties. As usual, any feedback or suggestions is welcome.
For those curious about the implementation, this finds its way all the
way down to the create callback, so that we can pick out true
create-time properties (e.g. volblocksize, future crypto properties).
The remaining properties are handled by the generic creation code.
- Eric
A. INTRODUCTION
A complicated ZFS installation will typically create a number of
datasets, each with their own property settings. Currently, this
requires several steps, one for creating the dataset, and one for each
property that must be configured:
# zfs create pool/fs
# zfs set compression=on pool/fs
# zfs set mountpoint=/export pool/fs
...
This has several drawbacks, the first of which is simply unnecessary
steps. For these complicated setups, it would be simpler to create the
dataset and all its properties at the same time. This has been
requested by the ZFS community, and resulted in the following RFE:
6367103 create-time properties
More importantly, it forces the user to instantiate (and often mount)
the dataset before assigning properties. In the case of the
''mountpoint'' property, it means that we create an inherited
mountpoint,
only to be later changed when the property is modified. This also makes
setting the ''canmount'' property (PSARC 2006/XXX) more
intuitive.
This RFE is also required for crypto support, as the encryption
algorithm must be known when the filesystem is created It also has the
benefit of cleaning up the implementation of other creation-time
properties (volsize and volblocksize) that were previously special
cases.
B. DESCRIPTION
This case adds a new option, ''zfs create -o'', which allows for
any ZFS
property to be set at creation time. Multiple ''-o'' options
can appear
in the same subcommand. Specifying the same property multiple times in
the same command results in an error. For example:
# zfs create -o compression=on -o mountpoint=/export pool/fs
The option ''-o'' was chosen over ''-p'' (for
''property'') to reserve this
for a future RFE:
6290249 zfs {create,clone,rename} -p to create parents
The functionality of ''zfs create -b'' has been superceded by
this new
option, though it will be retained for backwards compatibility. There
is no plan to formally obsolete or remove this options. For example:
# zfs create -b 16k -V 10M pool/vol
is equivalent to
# zfs create -o volblocksize=16k -V 10M pool/vol
If ''-o volblocksize'' is specified in addition to
''-b'', the resulting
behavior is undefined.
C. MANPAGE CHANGES
TBD
Eric Schrock wrote:> This case adds a new option, ''zfs create -o'', which allows for any ZFS > property to be set at creation time. Multiple ''-o'' options can appear > in the same subcommand. Specifying the same property multiple times in > the same command results in an error. For example: > > # zfs create -o compression=on -o mountpoint=/export pool/fsLooks fine to me. The one minor nit I have is that this even more shows up the positional parameters problem that zfs create and other zfs(1) commands have. Some people don''t mind it and I''ve created interfaces like it for years; recently however I''ve been trying to avoid doing so, or at least giving an alternative. For this case would it be possible to have this: # zfs create -o compression=on -o mountpoint=/export -o name=pool/fs The zfs list command already allows -o name (and zfs get should but doesn''t). I don''t feel that strongly about this but thing it might be helpful in some cases. -- Darren J Moffat
On Tue, Aug 15, 2006 at 08:56:00PM +0930, Darren J Moffat wrote:> Eric Schrock wrote: > > >This case adds a new option, ''zfs create -o'', which allows for any ZFS > >property to be set at creation time. Multiple ''-o'' options can appear > >in the same subcommand. Specifying the same property multiple times in > >the same command results in an error. For example: > > > > # zfs create -o compression=on -o mountpoint=/export pool/fs > > Looks fine to me. > > The one minor nit I have is that this even more shows up the positional > parameters problem that zfs create and other zfs(1) commands have. Some > people don''t mind it and I''ve created interfaces like it for years; > recently however I''ve been trying to avoid doing so, or at least giving > an alternative. > > For this case would it be possible to have this: > > # zfs create -o compression=on -o mountpoint=/export -o name=pool/fsI for one don''t have an issue with fixed positional parameters, they are fine by me. This is a good case of where they become an issue; however. Could you "mix and match" by keeping the current style assuming there are no -o options present? # zfs create pool/fs If you need to specify options, then they should all be options: # zfs create -o name=pool/fs -o mountpoint=/bar -o etc just a thought. I certainly like not having to run zfs twice in order to be able to set options, especially mountpoint. -brian
Brian Hechinger wrote:> Could you "mix and match" by keeping the current style assuming there > are no -o options present? > > # zfs create pool/fs > > If you need to specify options, then they should all be options: > > # zfs create -o name=pool/fs -o mountpoint=/bar -o etcI would be tempted to have two forms of the command. One (as exists today) takes no options. The other takes only options, but doesn''t need the "-o" markers. For example: zfs create pool/fs or zfs create mountpoint=/bar name=pool/fs compression=on In the second form, options may appear in any order. -- --Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: ed.gould.vcf Type: text/x-vcard Size: 262 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060815/20a92b56/attachment.vcf>
> This RFE is also required for crypto support, as the encryption > algorithm must be known when the filesystem is created.I''m deeply concerned about this requirement -- in short, basic principles of crypto hygene require both key and algorithm agility, and if you can''t change this after creation, the ability of ZFS to resist cryptographic attacks will be significantly diminished. I don''t think we''ll be doing crypto "right" until we can rekey and upgrade algorithms on the fly. - Bill
On Tue, Aug 15, 2006 at 02:57:50PM -0400, Bill Sommerfeld wrote:> > I''m deeply concerned about this requirement -- in short, basic > principles of crypto hygene require both key and algorithm agility, and > if you can''t change this after creation, the ability of ZFS to resist > cryptographic attacks will be significantly diminished. > > I don''t think we''ll be doing crypto "right" until we can rekey and > upgrade algorithms on the fly. >The copy-on-write nature of ZFS makes this extremely difficult, particularly w.r.t. to snapshots. That''s not to say it can''t be solved, only that it won''t be solved in the near term (i.e. within the next year). The timeframe for ZFS crypto support is much shorter, and this requirement is entirely reasonable for an initial implementation. That being said, this point has no particular bearing on this feature as designed. I will clarify the wording to note that this only a requirement for the "initial implementation" of ZFS crypto if that would be more appropriate. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On Tue, 2006-08-15 at 12:47 -0700, Eric Schrock wrote:> The copy-on-write nature of ZFS makes this extremely difficult, > particularly w.r.t. to snapshots. That''s not to say it can''t be solved, > only that it won''t be solved in the near term (i.e. within the next > year). The timeframe for ZFS crypto support is much shorter, and this > requirement is entirely reasonable for an initial implementation.So, maybe we''re doing these projects in the wrong order, then -- my experience with implementing systems using cryptography is that unless you design, implement, *and* test algorithm and key agility from the beginning, you will have to throw away a lot more than you originally expected to when you try to add it in later. - Bill
On Tue, Aug 15, 2006 at 06:12:47PM -0400, Bill Sommerfeld wrote:> On Tue, 2006-08-15 at 12:47 -0700, Eric Schrock wrote: > > > The copy-on-write nature of ZFS makes this extremely difficult, > > particularly w.r.t. to snapshots. That''s not to say it can''t be solved, > > only that it won''t be solved in the near term (i.e. within the next > > year). The timeframe for ZFS crypto support is much shorter, and this > > requirement is entirely reasonable for an initial implementation. > > So, maybe we''re doing these projects in the wrong order, then -- my > experience with implementing systems using cryptography is that unless > you design, implement, *and* test algorithm and key agility from the > beginning, you will have to throw away a lot more than you originally > expected to when you try to add it in later.This is particularly true for protocols (here everything is local though). A phase 0 project might put re-keying into zfs send/receive. Want to change algorithms, keys? zfs send|zfs receive, move filesystems around. In any case surely key management *has* to fit at least into zfs send or receive -- either send unencrypted or provide a key to zfs receive, else no zfs send/receive of encrypted filesystems, which could not possibly be acceptable. I''d expect key management to also fit into zfs scrubbing (ah, but scrubbing is a pool-wide thing). Want to re-key a whole filesystem? Scrub. Even so, I''d rather set up algorithms and keys in zfs create than in zfs set after creating the filesystem and then having to scrub the fs (though scrubbing a nearly empty filesystem should be no big deal, right). Nico --
Eric Schrock schrieb:> This RFE is also required for crypto support, as the encryption > algorithm must be known when the filesystem is created It also has the > benefit of cleaning up the implementation of other creation-time > properties (volsize and volblocksize) that were previously special > cases.Ok, but what about the toplevel FS in each pool? Then we need a -o option for "zpool create" also: zpool create pool .... zfs set compression=on pool Or will it be impossible to set encryption on directly on "pool" as opposed to "pool/fs"? Daniel
This was part of my original (unpublished) proposal, but deferred it for a few reasons: - We have discussed the possiblity of introducing pool-wide properties for a variety of reasons (such as background scrubbing intervals). I thought it best to delay dealing with the confluence of these options until a later date. - The functionality is trivial to extend at a later date. It''s introduction is a logical conclusion, but doesn''t seem a requirement at the moment. - It''s only really useful for pools on removable devices, where you want a one-to-one correspondence between the pool and a single filesystem. There are a number of other technical hurdles to overcome before this becomes an attractive option, so I don''t view the lack of this functionality as relevant in the enterprise space. Hope that helps, Eric On Wed, Aug 16, 2006 at 02:08:18AM +0200, Daniel Rock wrote:> > Ok, > > but what about the toplevel FS in each pool? Then we need a -o option for > "zpool create" also: > > zpool create pool .... > zfs set compression=on pool > > Or will it be impossible to set encryption on directly on "pool" as opposed > to "pool/fs"? > > > Daniel-- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock