Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)
A message that is not in the archive (sent off-list or not yet received): [email protected]
You don't need the tags, use dates. You can get the date range you want with an rlog of the ChangeSet file and then use those dates.
Quoted 69 lines · Mike Fedyk
----- Forwarded message from Andrea Arcangeli <[email protected]> -----
Delivery-date: Mon, 21 Jul 2003 11:52:43 -0700
Date: Mon, 21 Jul 2003 12:20:33 -0400
From: Andrea Arcangeli <[email protected]>
To: Stephan von Krawczynski <[email protected]>
Cc: [email protected], [email protected], [email protected],
[email protected], [email protected]
Subject: Re: Bug Report: 2.4.22-pre5: BUG inpage_alloc(fwd)
User-Agent: Mutt/1.4i
X-GPG-Key: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43
X-PGP-Key: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC C0 4B 81 1D 8C 15 C8 E5
X-Mailing-List: [email protected]
X-Spam-Status: No, hits=-3.1 required=5.0tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT, X_MAILING_LIST version=2.55X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)Quoted 18 lines · Stephan von Krawczynski
Quoted 15 lines · On Mon, 21 Jul 2003 10:49:06 +0200 Stephan von Krawczynski <[email protected]>…
Quoted 9 lines · On Fri, 18 Jul 2003 11:14:15 -0300 (BRT) Marcelo Tosatti…
I have just started stress testing a 8way OSDL box to see if I can reproduce the problem. I'm using pre6+axboes
BH_Syncpatch.I'm running 50 dbench clients on aic7xxx (ext2) and 50 dbench clients on DAC960 (ext3). Lets see what happens.
After lunch I'll keep looking at the oopses. During the morning I only had time to setup the OSDL box and start the tests.
Hello Marcelo,
Quoted 8 lines
Quoted 2 lines
have you seen anything in your tests? My box just froze again after 3 days during NFS action. This was with pre6, I am switching over to pre7.
I managed to freeze the pre7 box within these few hours. There was no nfs involved, only tar-to-tape.
I switched back to 2.4.21 to see if it is still stable.
Is there a possibility that the i/o-scheduler has another flaw somewhere (just like during mount previously) ...is it a scsi tape? Is the tape always involved? there are
st.cupdates between 2.4.21 to 22pre7. you can try to back them out.If only the BKCVS would provide the tags in all files and not only in the file ChangeSets it would be very easy again to extract all the
st.cupdates. What happened to the BKCVS, why aren't the tags present in all the files anymore? Is it a mistake or intentional?You should also provide a SYSRQ+P/T of the hang or we can't debug it at all.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/----- End forwarded message -----
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi Larry,
Quoted 2 lines · Larry McVoy
You don't need the tags, use dates. You can get the date range you want with an rlog of the ChangeSet file and then use those dates.
I realized I could do this, and it can of course be automated with an additional bkcvs specific hack in cvsps. But the tag in every file would have kept the functionality generic with the already available -r option, and since I can't see any downside in the tag in the files, I prefer that generic way.
But if you're sure the tags aren't coming back we can start adding the automation to cvsps.
thanks,
Andrea
Quoted 11 lines · Andrea Arcangeli
Hi Larry,
Quoted 2 lines · Larry McVoy
You don't need the tags, use dates. You can get the date range you want with an rlog of the ChangeSet file and then use those dates.
I realized I could do this, and it can of course be automated with an additional bkcvs specific hack in cvsps. But the tag in every file would have kept the functionality generic with the already available -r option, and since I can't see any downside in the tag in the files, I prefer that generic way.
The tags means that each file gets modified for each tag and then we have to transfer the whole tree after a tag. It thrashes the hell out of the disk too, for no good reason.
Also note that there are nowhere near as many tags as there are commits in the CVS tree. So by using tags you are restricting yourself to coarse granularity in your bug hunts.
Quoted 2 lines
But if you're sure the tags aren't coming back we can start adding the automation to cvsps.
Please do, we're not adding the tags.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 13 lines · Larry McVoy
Quoted 11 lines · Andrea Arcangeli
Hi Larry,
Quoted 2 lines · Larry McVoy
You don't need the tags, use dates. You can get the date range you want with an rlog of the ChangeSet file and then use those dates.
I realized I could do this, and it can of course be automated with an additional bkcvs specific hack in cvsps. But the tag in every file would have kept the functionality generic with the already available -r option, and since I can't see any downside in the tag in the files, I prefer that generic way.
Quoted 7 lines
The tags means that each file gets modified for each tag and then we have to transfer the whole tree after a tag. It thrashes the hell out of the disk too, for no good reason.
Also note that there are nowhere near as many tags as there are commits in the CVS tree. So by using tags you are restricting yourself to coarse granularity in your bug hunts.
the granularity wasn't the issue, I need this feature anyways out of cvsps (cvsps is exactly the thing that generates the changesets out of the coarse granularity of the tags). the checkout/rsync being more expensive sounds a fair enough argument for implementing the feature in cvsps where it will be zero write cost.
since we're talking about bkcvs, I also would have a feature wish for the repository export in rsync.kernel.org: would it be possible to export a sequence number increased once before a transfer, and increased a second time after the tree is coherent again? When the sequence number is even and it didn't change before and after the rsync, we'll know the current status is coherent and we don't need to repeat the rsync (after some delay). Or is there any other mechanism that guarantees to get a coherent repository out of rsync?
thanks,
Andrea
Quoted 3 lines · Andrea Arcangeli
since we're talking about bkcvs, I also would have a feature wish for the repository export in rsync.kernel.org: would it be possible to export a sequence number increased once before a transfer
I don't manage the rsync trees, HPA does that. Peter?
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi,
Quoted 22 lines · Andrea Arcangeli
Quoted 13 lines · Larry McVoy
Quoted 11 lines · Andrea Arcangeli
Hi Larry,
Quoted 2 lines · Larry McVoy
You don't need the tags, use dates. You can get the date range you want with an rlog of the ChangeSet file and then use those dates.
I realized I could do this, and it can of course be automated with an additional bkcvs specific hack in cvsps. But the tag in every file would have kept the functionality generic with the already available -r option, and since I can't see any downside in the tag in the files, I prefer that generic way.
Quoted 7 lines
The tags means that each file gets modified for each tag and then we have to transfer the whole tree after a tag. It thrashes the hell out of the disk too, for no good reason.
Also note that there are nowhere near as many tags as there are commits in the CVS tree. So by using tags you are restricting yourself to coarse granularity in your bug hunts.
Quoted 5 lines
the granularity wasn't the issue, I need this feature anyways out of cvsps (cvsps is exactly the thing that generates the changesets out of the coarse granularity of the tags). the checkout/rsync being more expensive sounds a fair enough argument for implementing the feature in cvsps where it will be zero write cost.
while writing the code to do it, I noticed the heuristic was already there in cvsps ;), and it is generic (not hardwired to the ChangeSet file). I had bad luck diffing with -r v2_4_22-pre3 (which is missing from the changeset file too, so I guess the info is missing in bitkeeper as well, not just bkcvs). Infact probably it's a long time that you dropped the tags from all files, and I noticed only now after getting the error diffing against 22pre3 ;).
Quoted 8 lines
since we're talking about bkcvs, I also would have a feature wish for the repository export in rsync.kernel.org: would it be possible to export a sequence number increased once before a transfer, and increased a second time after the tree is coherent again? When the sequence number is even and it didn't change before and after the rsync, we'll know the current status is coherent and we don't need to repeat the rsync (after some delay). Or is there any other mechanism that guarantees to get a coherent repository out of rsync?
Peter, any suggestion on this? Larry said it's all on your side, so I assume you're running bkcvs yourself, or Larry is already providing you a locking mechanism that serializes against bkcvs and that allows you to fetch a coherent of the cvs repository. w/o this last locking bit that allows to export a coherent copy of the repository, I can't easily automate the stuff based on a local repository and I've to switch to the remote one, despite having it local is more flexible (and much faster for local browsing) and rsync -z is faster.
Many thanks again to both of you and last but not the least to David Mansfiel (cvsps author).
Andrea
Hi,
Quoted 8 lines · Andrea Arcangeli
Peter, any suggestion on this? Larry said it's all on your side, so I assume you're running bkcvs yourself, or Larry is already providing you a locking mechanism that serializes against bkcvs and that allows you to fetch a coherent of the cvs repository. w/o this last locking bit that allows to export a coherent copy of the repository, I can't easily automate the stuff based on a local repository and I've to switch to the remote one, despite having it local is more flexible (and much faster for local browsing) and rsync -z is faster.
Any news on this? I'm still looking into a way to rsync a coherenty copy of the cvs repository.
Andrea