When creating a new zfs volume the calculated refreservation is greater than volsize to account for number of copies and metadata:
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
