When creating a new zfs volume the calculated refreservation is greater than
volsize to account for number of copies and metadata:

Advertising

root@test:~# zfs create -V 1G rpool/test
root@test:~# zfs get -Hp volsize,volblocksize,copies,refreservation rpool/test
rpool/test volsize 1073741824 local
rpool/test volblocksize 8192 -
rpool/test copies 1 default
rpool/test refreservation 1107820544 local
After I set refreservation to none, I am no longer able to reset refreservation
back to the required refreservation, since there is a check in libzfs that
prevents it:
root@danstore2:/lib# zfs set refreservation=none rpool/test
root@danstore2:/lib# zfs get -Hp volsize,volblocksize,copies,refreservation
rpool/test
rpool/test volsize 1073741824 local
rpool/test volblocksize 8192 -
rpool/test copies 1 default
rpool/test refreservation 0 local
root@danstore2:/lib# zfs set refreservation=1107820544 rpool/test
cannot set property for 'rpool/test': 'refreservation' is greater than current
volume size
Is this an intended behavior or a bug?
The same is true for reservation. Setting reservation on a volume is also
limited to volsize, but reading the documentation
(http://docs.oracle.com/cd/E19253-01/819-5461/gazvb/index.html) I understand
reservation may be as large as the user wants it to be. I think this is so
because:
1. "The quota and reservation properties are convenient for managing disk space
consumed by datasets and their descendents"
2. " … descendents, such as snapshots and clones"
If I understand correctly, the reservation on a volume accounts for all space
consumed by the volume, its metadata and copies, and its descendant snapshots
and clones, so it does not make any sense to limit it to volsize.
Getting into libzfs code, I found that zfs_valid_proplist (in libzfs_dataset.c)
specifically checks and prevents setting reservation and refreservation to more
than volsize. I think the check should be removed for ZFS_PROP_RESERVATION, and
limited to zvol_volsize_to_reservation(volsize, nvl) for
ZFS_PROP_REFRESERVATION (when type == ZFS_TYPE_VOLUME).
Dan
PS: sorry if this message is a duplicate (I sent the original one from the
wrong account).
On 6 Jul 2012, at 0:00, Stefan Ring wrote:
>> Actually, a write to memory for a memory mapped file is more similar to
>> write(2). If two programs have the same file mapped then the effect on the
>> memory they share is instantaneous because it is the same physical memory.
>> A mmapped file becomes shared memory as soon as it is mapped at least twice.
>
> True, for some interpretation of "instantaneous". It does not
> establish a happens-before relationship though, as
> store-munmap/mmap-load does.
> _______________________________________________
> 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