> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Bill Sommerfeld
> > But simply creating the snapshot on the sending side should be no
> problem.
> By default, zvols have reservations equal to their size (so that writes
> don't fail due to the pool being out of space).
> Creating a snapshot in the presence of a reservation requires reserving
> enough space to overwrite every block on the device.

This is surprising, because it's not like the "normal" zfs behavior.  Normal 
ZFS does not reserve snapshot space to guarantee you can always completely 
overwrite every single used block of every single file in the system.  It just 
starts consuming space for changed blocks, and if you fill up the zpool, 
further writes are denied until you delete some snaps.

But you're saying it handles zvols differently - That when you create a zvol, 
it reserves enough space for it, and when you snapshot it, it reserves enough 
space to completely overwrite it and keep both the snapshot and the current 
live version without running out of storage space.  I never heard that before - 
and I can see some good reasons to do it this way - But it's surprising.

Based on what I'm hearing now, it also seems - Upon zvol creation, you create a 
reservation.  Upon the first snapshot, you double the reservation, but upon 
subsequent snapshots, you don't need to increase the reservation each time.  
Because snapshots are read-only, the system is able to account for all the used 
space of the snapshots, plus a reservation for the "live" current version.  
Total space reserved will be 2x the size of the zvol, plus the actual COW 
consumed space for all the snapshots.

The point is to guarantee that writes to a zvol will never be denied, 
presumably because there's an assumption zvol's are being used by things like 
VM's and iscsi shares, which behave very poorly if write is denied.  Unlike 
"normal" files, where write denied is generally an annoyance but doesn't cause 
deeper harm, such as virtual servers crashing.

There's another lesson to be learned here.

As mentioned by Matthew, you can tweak your reservation (or refreservation) on 
the zvol, but you do so at your own risk, possibly putting yourself into a 
situation where writes to the zvol might get denied.

But the important implied meaning is the converse - If you have guest VM's in 
the filesystem (for example, if you're sharing NFS to ESX, or if you're running 
VirtualBox) then you might want to set the reservation (or refreservation) for 
those filesystems modeled after the zvol  behavior.  In other words, you might 
want to guarantee that ESX or VirtualBox can always write.  It's probably a 
smart thing to do, in a lot of situations.

zfs-discuss mailing list

Reply via email to