[zfs-discuss] currupted pool [was: slow zfs]
tompos at martos.bme.hu
Sun May 19 14:51:49 EDT 2013
On 05/19/2013 12:07 PM, Turbo Fredriksson wrote:
> On May 19, 2013, at 8:10 AM, Papp Tamas wrote:
>> It's unacceptable.
> Why? Lots of memory is a requirement. If you don't have that,
> 'strange and possibly fatal' things might happen. You have
> been warned...
Because it's not the way a production system should work.
First, define "lots of memory".
Second, it should not crash (I disagree with Gordan at this point). Or if it does (like an oom),
don't do it this way, but with a helpful messages, what's going on or anything other then a pure
panic. How can you be sure about memory? As I said I removed a lot of data. Less memory should be
enough, then before!
Third, you cannot be serious, that pool corruption is acceptable in case there is no enough memory.
I would be the happiest if at the end it turns out, that adding more memory fixes the pool.
>> Why this hardware is ancient for debugging. What's the problem with that?
> Do I really have to tell you AGAIN?!
I don't see, why someone could not debug the code just because there is less memory.
I'm not a developer but I guess, you're. Probably you're right, of course I cannot do anything else,
then accept your opinion:)
>> Basically this HW is not so bad. I see discussions in the list with 1-2GB RAM, though without dedup.
> Yes. Without dedup. That's the point, isn't it?
Yes, that's it. And read above, I removed a lots of data so in theory it should be enough now.
I can remove more, but I still didn't do that, since it's irreversible...
>> BTW, it happens if there is no activity on the filesystem, just mounted.
More information about the zfs-discuss