4 ms·

Isn't that a bit of rewriting the history? Originally the roadmap was that these kinds of features would be added based on the mythical block pointer rewrite. E

Isn't that a bit of rewriting the history? Originally the roadmap was that these kinds of features would be added based on the mythical block pointer rewrite. Eventually BPR and thus all features requiring it were put on ice.

kbenson 7y ago
What specifically are you replying to? I'm not sure I recognize something in the article this applies to (but that could just be me interpreting what was presented differently than you).
- the8472 7y ago
  > One fundamental reason is that ZFS is philosophically and practically opposed to rewriting existing data on disk; once written, it wants everything to be completely immutable ZFS was not philosophically opposed to those ideas. They were just dropped at some point.
  - nickik 7y ago
    They were dropped because getting them fully correct and implemented was really hard and required a lot of work that nobody really wanted to pay for.
    - phs2501 7y ago
      What's funny is now ZFS is used on SSDs, where that kind of rewriting is constantly happening behind the scenes (even if you're not writing it's constantly doing housekeeping for degraded blocks, especially on modern denser flash).
boomboomsubban 7y ago
I wouldn't call it rewriting history. ZFS had plans to eventually develop the more complicated code to handle reshaping pools, but that never happened and the described system is the one still in place.
secabeen 7y ago
Yeah, I think Sun/Oracle recognized that there was a subset of their user base that would greatly benefit from BPR and all the associated features that come from it, but that it wasn't their core customers, so it wasn't included in the initial implementation (in my experience, most enterprise customers would rather replace an entire array that was full than expand or reshape it.) Had Sun remained the powerhouse it was, the BPR would probably probably have eventually gotten done, but with the smaller resources devoted to ZFS development now vs in the Sun days, it's gotten kicked way down the priority list.
- toast0 7y ago
  Enterprise users are most often using enterprise servers with fancy built in disk enclosures, and they're likely to fill those up with disks. Expanding the storage by replacing with higher capacity disks makes sense; expanding by using more disks isn't as likely. And changing the configuration to have fewer disks is also less likely; you paid for all those slots, so they're going to be filled.
  - gravitas 7y ago
    Enterprise users are most often using enterprise servers with fiber HBAs and SAN.
  - tjoff 7y ago
    > Expanding the storage by replacing with higher capacity disks makes sense That is an insanely time consuming operation that also increases the risk of data loss as you have less redundancy during the expansion. An enterprise ought to just migrate the entire pool/content to somewhere else and redo it completely. Expanding by replacing with higher capacity drives just feels like a hack and afterthought that only hobbyists would actually make use of.
    - the8472 7y ago
      > as you have less redundancy during the expansion. If the old device is not faulty then the replace operation will keep both old and new in the array until it is complete. > An enterprise ought to just migrate the entire pool/content to somewhere else and redo it completely. That's also an option with send/receive, but that involves downtime. Drive replacements can be done on a live system. Server grade hardware generally supports hotplug.

kbenson 7y ago

What specifically are you replying to? I'm not sure I recognize something in the article this applies to (but that could just be me interpreting what was presented differently than you).

the8472 7y ago
> One fundamental reason is that ZFS is philosophically and practically opposed to rewriting existing data on disk; once written, it wants everything to be completely immutable ZFS was not philosophically opposed to those ideas. They were just dropped at some point.
- nickik 7y ago
  They were dropped because getting them fully correct and implemented was really hard and required a lot of work that nobody really wanted to pay for.
  - phs2501 7y ago
    What's funny is now ZFS is used on SSDs, where that kind of rewriting is constantly happening behind the scenes (even if you're not writing it's constantly doing housekeeping for degraded blocks, especially on modern denser flash).

boomboomsubban 7y ago

I wouldn't call it rewriting history. ZFS had plans to eventually develop the more complicated code to handle reshaping pools, but that never happened and the described system is the one still in place.

secabeen 7y ago

Yeah, I think Sun/Oracle recognized that there was a subset of their user base that would greatly benefit from BPR and all the associated features that come from it, but that it wasn't their core customers, so it wasn't included in the initial implementation (in my experience, most enterprise customers would rather replace an entire array that was full than expand or reshape it.) Had Sun remained the powerhouse it was, the BPR would probably probably have eventually gotten done, but with the smaller resources devoted to ZFS development now vs in the Sun days, it's gotten kicked way down the priority list.

toast0 7y ago
Enterprise users are most often using enterprise servers with fancy built in disk enclosures, and they're likely to fill those up with disks. Expanding the storage by replacing with higher capacity disks makes sense; expanding by using more disks isn't as likely. And changing the configuration to have fewer disks is also less likely; you paid for all those slots, so they're going to be filled.
- gravitas 7y ago
  Enterprise users are most often using enterprise servers with fiber HBAs and SAN.
- tjoff 7y ago
  > Expanding the storage by replacing with higher capacity disks makes sense That is an insanely time consuming operation that also increases the risk of data loss as you have less redundancy during the expansion. An enterprise ought to just migrate the entire pool/content to somewhere else and redo it completely. Expanding by replacing with higher capacity drives just feels like a hack and afterthought that only hobbyists would actually make use of.
  - the8472 7y ago
    > as you have less redundancy during the expansion. If the old device is not faulty then the replace operation will keep both old and new in the array until it is complete. > An enterprise ought to just migrate the entire pool/content to somewhere else and redo it completely. That's also an option with send/receive, but that involves downtime. Drive replacements can be done on a live system. Server grade hardware generally supports hotplug.