Migration from the KQ Implementation
stevecs at chaven.com
Thu May 5 17:43:18 EDT 2011
Gordan Bobic wrote:
> I don't agree with this. Although the features are merged for reasons of
> performance, logically they are still separate, and repairing a pool (MD
> equivalent) should be doable independently of higher level functions.
Then perhaps you can detail out exactly what you want a 'fsck' to DO? The numbers of variables involved and their possible permutations are enormous and without bounding assumptions, not possible to handle all scenarios. I run into this all the time with server/network/san etc RCA's. "why didn't X error show up when we tested the environment" Just like in those cases if your 'test' tool is not set up to specifically look for it, you won't see it.
>One thing we have to remember is that advanced file systems like ZFS are
>usually used in cases where the amount of data is very large. That makes
>availability of good recovery tools more important because restoring
>from backups will take a prohibitively long time compared to fsck. Most
>people (myself included) do not fully grok just how much data 10TB is
>until you actually have to do something with _all_ of it (e.g. copy it
>from a backup server).
I do not disagree that on-line recovery would be the better choice for nearly any dataset size; as I also have several large datasets (50-100TB range) so understand the loss of time issues. My only point is the first step in trying to solve an issue is to have a detailed description of what specifically we need to solve and then come up with the plan to accomplish that (and that may not mean 'fsck' but a change to the original architecture so as not have the problem in the first place).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zfs-discuss