Mike Gerdts wrote: > I'm curious as to how ZFS manages space (free and used) and how > its usage interacts with thin provisioning provided by HDS > arrays. Is there any effort to minimize the number of provisioned > disk blocks that get writes so as to not negate any space > benefits that thin provisioning may give?
I was trying to compose an email asking almost the exact same question, but in the context of array-based replication. They're similar in the sense that you're asking about using already-written space, rather than to go off into virgin sectors of the disks (in my case, in the hope that the previous write is still waiting to be replicated and thus can be replaced by the current data) > > > Background & more detailed questions: > > In Jeff Bonwick's blog[1], he talks about free space management > and metaslabs. Of particular interest is the statement: "ZFS > divides the space on each virtual device into a few hundred > regions called metaslabs." > > 1. http://blogs.sun.com/bonwick/entry/space_maps I wish I'd have seen this blog while I was composing my question... it answers some of my questions about how things work (plus Jeff's zfs_block_allocation entry actually moots most of my comments since they've already been implemented) (snip) > > As data is deleted, do the freed blocks get reused before never > used blocks? I didn't see any code where this would happen. I would really love to see a zpool setting where I can specify the reuse algorithm. (For example: zpool set block_reuse_policy=mru or =dense or =broad or =low) MRU (most recently used) in the hopes that the storage replication hasn't yet committed the previous write to the other side of the WAN DENSE (reuse any previously-written space) in the thin-provisioning case BROAD (venture off into new space when possible) for media that has a rewrite cycle limitations (flash drives) to spread the writes over as much of the media as possible LOW (prioritize low-block# space) would provide optimal rotational latency for random i/o in the fututre and might be a special case of the above. The corresponding HIGH would improve sequential i/o. (Implementation is left as an exercise to the reader ;) > > Is there any collaboration between the storage vendors and ZFS > developers to allow the file system to tell the storage array > "this range of blocks is unused" so that the array can reclaim > the space? I could see this as useful when doing re-writes of > data (e.g. crypto rekey) to concentrate data that had become > scattered into contiguous space. Deallocating storage space is something that nobody seems to be good at: ever tried to shrink a filesystem? Or a ZFS pool? Or a SAN RAID group? --Joe _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
