Hi Rich, This is the best summary I have seen. [china folks say, older ginger more satisfying, true]
Just one thing I would like to add - It also depends on the encryption technique and algorism. Today we are doing private key encryption that without the key, you cannot read the data. Some used a public "public key" approach, that you can read the data without the key, but just misleading. The private key approach saves a lot of blocks in data writing, but carries the risk of cannot duplicate or duplicating too many of the key. The public "public key" approach takes much much more storage space to store the real data, but less risky, in some views. Again, how to do data storage is an art. Sun folks can guide with a good taste, but they are not limiting anyone's free will to do IT. Best, z, going chinatown for dinner soon ----- Original Message ----- From: "Richard Elling" <richard.ell...@sun.com> To: "Tim" <t...@tcsac.net> Cc: <zfs-discuss@opensolaris.org> Sent: Friday, January 16, 2009 5:28 PM Subject: Re: [zfs-discuss] 4 disk raidz1 with 3 disks... > Tim wrote: >> On Thu, Jan 15, 2009 at 10:20 PM, Jonny Gerold <j...@thermeon.com >> <mailto:j...@thermeon.com>> wrote: >> >> Meh this is retarted. It looks like zpool list shows an incorrect >> calculation? Can anyone agree that this looks like a bug? >> >> r...@fsk-backup:~# df -h | grep ambry >> ambry 2.7T 27K 2.7T 1% /ambry >> >> r...@fsk-backup:~# zpool list >> NAME SIZE USED AVAIL CAP HEALTH ALTROOT >> ambry 3.62T 132K 3.62T 0% ONLINE - >> >> r...@fsk-backup:~# zfs list >> NAME USED AVAIL REFER MOUNTPOINT >> ambry 92.0K 2.67T 26.9K /ambry >> >> >> From what I understand: >> >> zpool list shows total capacity of all the drives in the pool. df shows >> usable capacity after parity. > > More specifically, from zpool(1m) > > These space usage properties report actual physical space > available to the storage pool. The physical space can be > different from the total amount of space that any contained > datasets can actually use. The amount of space used in a > raidz configuration depends on the characteristics of the > data being written. In addition, ZFS reserves some space for > internal accounting that the zfs(1M) command takes into > account, but the zpool command does not. For non-full pools > of a reasonable size, these effects should be invisible. For > small pools, or pools that are close to being completely > full, these discrepancies may become more noticeable. > > Similarly, from zfs(1m) > The amount of space available to the dataset and all its > children, assuming that there is no other activity in > the pool. Because space is shared within a pool, availa- > bility can be limited by any number of factors, includ- > ing physical pool size, quotas, reservations, or other > datasets within the pool. > > IMHO, this is a little bit wordy, in an already long man page. > If you come up with a better way to say the same thing in > fewer words, then please file a bug against the man page. > -- richard > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
