[DRBD-user] Reproduceable error - creating a single directory causes drbd to fail

[Lars Ellenberg]

/ 2007-02-08 09:26:45 -0500
\ Dan Gahlinger:
> >and that would be which kernel and drbd version/revision exactly?
> >(sorry, no 10.2 handy right now)
> 
> Kernel: 2.6.18.2-34 (x86) SMP
> Although I've tried slightly older kernel too (the one from suse
> 10.1) dont have it handy though.
> 
> DRBD version:
> "out of the box" - 0.7.22-30
> 
> >and if you do this without drbd,
> >it does behave fine, presumably?
> 
> It works fine without drbd, yes.
> 
> 
> >what is in kernel log before "read-only file system" ?
> >any oopes, BUG()s, stacktraces or drbd related messages?
> 
> no errors in the kernel log or messages, no traces, no bugs, no errors.

no way. there _HAS_ to be a log from the ext3 that it remounts readonly
because of something.
if not, you are looking at the wrong logfile.

> >what file system?
> 
> ext3. I've never been able to get drbd to work with anything else.
> 
> >does it happen
> > without drbd ?
> Yes!

uhm, you mean no, right?

> > with drbd StandAlone?
> Yes!
> > with drbd Connected?
> 
> Yes!
> 
> In fact, I've nailed it down a bit, to do "quick testing"
> I created a test directory as follows (as root):
> 
> mkdir /test
> cd /test
> mkdir A
> tar -cvf test.tar .
> 
> then copied this 10k tar file to the partition I just setup with DRBD,
> 
> and tried to untar it.
> 
> DRBD will "crash" every time!  By this I mean, it cannot create the directory,
> and instantly puts the partition into "read-only mode"

it is not DRBD that remounts anything readonly.
it is the ext3 file system, normally because of io-errors.
and it will log why. I need that error message.

> Every single time.
> 
> 
> I can untar hundreds of megs, of thousands of files, and it's fine.
> But try and untar a single directory, and wham! every time.
> 
> what's up with this? weirder and weirder.

does a mkdir there have the same effect?

> >did you run memtest
> 
> 
> No, but I'm not sure how this applies. the system runs perfectly without DRBD.
> such a small simple test, it's not ram.

now, see, we have fileservers in production.
database clusters.  quite a few of them.
terabytes of storage.

never heard of what you describe,
unless it was user error -- or bad hardware.

-- 
: Lars Ellenberg                            Tel +43-1-8178292-0  :
: LINBIT Information Technologies GmbH      Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna/Europe    http://www.linbit.com :
__
please use the "List-Reply" function of your email client.