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 opt
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.
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 sol
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
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 atta
> 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 creatio
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 etc
I would be tempted to have two
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 mult
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:
#
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. volblocks
10 matches
Mail list logo
