Migration from the KQ Implementation

Steve Costaras 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...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20110505/ae215f14/attachment.html>


More information about the zfs-discuss mailing list