> 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 zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
