Thank you, it is exactly what I needed. Trying to compile this thing on a SPARC
system :)
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Also, when the IV is stored you can more easily look for accidental IV
re-use, and if you can find hash collisions, them you can even cause IV
re-use (if you can write to the filesystem in question). For GCM IV
re-use is rather fatal (for CCM it's bad, but IIRC not fatal), so I'd
not use GCM with
> "dm" == David Magda writes:
dm> The other thing is that with the growth of SSDs, if more OS
dm> vendors support "dynamic" sectors, SSD makers can have
dm> different values for the sector size
okay, but if the size of whatever you're talking about is a multiple
of 512, we don't
Hi Don,
I'm no snapshot expert but I think you will have to remove the previous
receiving side snapshots, at least.
I created a file system hierarchy that includes a lower-level snapshot,
created a recursive snapshot of that hierarchy and sent it over to
a backup pool. Then, did the same steps a
On 17/11/2010 21:58, Bill Sommerfeld wrote:
In particular, the mechanism by which dedup-friendly block IV's are
chosen based on the plaintext needs public scrutiny. Knowing Darren,
it's very likely that he got it right, but in crypto, all the details
matter and if a spec detailed enough to allow
Hi Cindy,
> I haven't seen this in a while but I wonder if you just need to set the
> bootfs property on your new root pool and/or reapplying the bootblocks.
>
> Can you import this pool booting from a LiveCD and to review the
> bootfs property value? I would also install the boot blocks on the
>
On Wed, Nov 17, 2010 at 01:58:06PM -0800, Bill Sommerfeld wrote:
> On 11/17/10 12:04, Miles Nordin wrote:
> >black-box crypto is snake oil at any level, IMNSHO.
>
> Absolutely.
As Darren said, much of the design has been discussed in public, and
reviewed by cryptographers. It'd be nicer if we ha
Hi,
Following our new strategy with regard to Oracle code, we (GRUB
maintainers) have decided to grant an exception to our usual policy and
import ZFS code from grub-extras into official GRUB.
Our usual policy is to require copyright assignment for all new code, so
that FSF can use it to defend u
W dniu 2010-12-01 15:19, Menno Lageman pisze:
f...@ll wrote:
Hi,
I must send zfs snaphost from one server to another. Snapshot have size
130GB. Now I have question, the zfs have any limit of sending file?
If you are sending the snapshot to another zpool (i.e. using 'zfs send
| zfs recv') the
I verified that this bug exists in OpenSolaris as well. The problem is that
we can't destroy the old filesystem "a" (which has been renamed to
"rec2/recv-2176-1"
in this case). We can't destroy it because it has a child, "b". We need to
rename "b" to be under the new "a". However, we are not re
That's for pointing me towards that site! Saying that "txg_synctime_ms"
controls zfs's breathing was how I was thinking about it. Great way to
describe it! Unfortunately setting txg_synctime_ms to 1000 or even 1 didn't
make an improvement.
I tried adding the "disable-ohci=true" to the GRUB boot me
On 11/17/10 12:04, Miles Nordin wrote:
black-box crypto is snake oil at any level, IMNSHO.
Absolutely.
Congrats again on finishing your project, but every other disk
encryption framework I've seen taken remotely seriously has a detailed
paper describing the algorithm, not just a list of featu
On Thu, December 2, 2010 00:14, Miles Nordin wrote:
> NTFS has 4KByte allocation units, so all you have to do is make sure
> the NTFS partition starts at an LBA that's a multiple of 8, and you
> have full performance. Probably NTFS is the reason WD has chosen
> 4kByte.
4K wasn't chosen by WD (al
13 matches
Mail list logo
