As I mentioned in a branch of this thread: While we can't discuss futures in this forum, I can tell you the '255 limit' goes way up in the near future. The even better news is that it wont be an issues for file level flexclone anymore either. If you'f like specific information, please request a meeting with your NetApp SE.
- "How does the "max shared blocks" limit get reached ?"
The 'max shared' is a per block limit. The deduplication and file level flexclone technologies use references to blocks from the same of different files/luns in order to eliminate block duplication.
- "I hope it's not as simple as having more than 255 similar blocks between two LUNs, otherwise 1MB worth of zeroed blocks inside a LUN would make a clone impossible?"
The 'max shared' is a per block limit. Once a block has been referenced 255 times, it must be copied before something else can reference it. This does not make cloning impossible, but it can make it slower. We (the developers of RCU) found that we could get a file which has some blocks at "max shared" duplicated quicker using ndmpcopy than waiting for the file level flexclone to duplicate a bunch of small block ranges. * Please see my note above about how this changes in the near future.
- "This would basically imply that file clones don't play well with deduplication."
On the contrary, these technologies complement each other very well. The file level flexclone starts the volume off with very few duplicated block and the batch deduplication keeps it that way.