Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 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.