Bill Sommerfeld wrote:
On Fri, 2006-07-14 at 07:03, Darren J Moffat wrote:
The current plan is that encryption must be turned on when the file
system is created and can't be turned on later. This means that the
zfs-crypto work depends on the RFE to set properties at file system
creation time.
Jeff Victor wrote:
Why? Is the 'data is encrypted' flag only stored in filesystem
metadata, or is that flag stored in each data block?
Like compression and which checksum algorithm it will be stored in
every dmu object.
If the latter is
true, it would be possible (though potentially time-c
Joseph Mocker wrote:
Jeff Victor wrote:
And if that file system is multiple terrabytes would you be okay
with there being a read and write lock while this runs ?
I am only guessing, but when encryption is "important enough" the
answer is "yes." But the next question is then "is this s
Jeff Victor wrote:
And if that file system is multiple terrabytes would you be okay with
there being a read and write lock while this runs ?
I am only guessing, but when encryption is "important enough" the
answer is "yes." But the next question is then "is this situation
common enough
Darren J Moffat wrote:
Darren Reed wrote:
Hmmm, well, I suppose the same problem might apply to
encrypting data too...so maybe what I need is a zfs command
that will walk the filesystem's data tree, read in data and
write it back out according to the current data policy.
And if that file syst
On 7/16/06, Torrey McMahon <[EMAIL PROTECTED]> wrote:
Dick Davies wrote:
> On 15/07/06, Torrey McMahon <[EMAIL PROTECTED]> wrote:
>> eric kustarz wrote:
>> > martin wrote:
>
>> > To monitor activity, use 'zpool iostat 1' to monitor just zfs
>> > datasets, or iostat(1M) to include non-zfs devices.
Dick Davies wrote:
On 15/07/06, Torrey McMahon <[EMAIL PROTECTED]> wrote:
eric kustarz wrote:
> martin wrote:
> To monitor activity, use 'zpool iostat 1' to monitor just zfs
> datasets, or iostat(1M) to include non-zfs devices.
Perhaps Martin was asking for something a little more robust. So
ZFS will generate error events through FMA and they will be visible via
syslog or fmdump. The hot spares facility will also listen for vdev
failures to determine when to automatically kick in a hot spare.
- George
Dick Davies wrote:
On 15/07/06, Torrey McMahon <[EMAIL PROTECTED]> wrote:
eric
On 15/07/06, Torrey McMahon <[EMAIL PROTECTED]> wrote:
eric kustarz wrote:
> martin wrote:
> To monitor activity, use 'zpool iostat 1' to monitor just zfs
> datasets, or iostat(1M) to include non-zfs devices.
Perhaps Martin was asking for something a little more robust. Something
like SNMP tr
