On Tue, 24 Apr 2012, Robin Humble wrote:
On Tue, Apr 24, 2012 at 02:45:39PM +1000, Tim Connors wrote:
On Tue, 24 Apr 2012, Peter Ross wrote:
It looks as I have to keep an eye on it. I mirror a samba server here, maybe I should do it on another box..
Do you use snapshots? Extensively? Perhaps continual use of snapshots greatly fragments the pool. I was personally hoping not to lose 20% of my disk! But since my usage won't involve snapshots (except every month or so when I send a snapshot to offsite storage then immediately remove the local snapshot), maybe I'll be ok.
ZFS is fragmentation city, pretty much by design - that's what you get with COW and variable block sizes.
Yeah, that's what I feared. Why can't someone invent a perfect filesystem (that's why I didn't invent ZFS[1] :), dagnamit?
I don't think ZFS snapshots are any different to all the other i/o from a fragmentation point of view. what is the difference between a fs being 50% full with static snapshots or 50% full with static data? it's all just blocks that can't be shifted around.
Does zfs send or similar defragment objects before sending? Doubt it - it'd make sending extremely slow! But it would be nice to be able to do something like send somewhere (my storage about to go offsite) and back again occasionally. [1] It's like back in uni when we were tasked with writing a BIGNUM handler in assembler. The memory allocator was brk(). I tried forever to write an allocator thinking that I could somehow reclaim memory once I finished with it. I was even going to do double indirection. But I failed, and decided just to do a half arsed job and get the rest of the project working. Then I found out that the pros only ever grow memory and never shrink it again, because when combined with fragmentation, you never have space at the end to be able to shrink. That's why you end up with bloated pigs like mozilla always ever expanding and never shrinking when you close a bunch of tabs. You can't shrink unless brk() takes a negative number and all your allocations were at the start of your heap. I wouldn't have invented *THAT* API! -- Tim Connors