Tobias Diedrich wrote: > Steinar H. Gunderson wrote: > > On Tue, May 29, 2007 at 07:21:33PM +0200, Tobias Diedrich wrote: > > > After upgrading nfs-kernel-server to a new testing version, > > > nfs started behaving erratically. Upgrade to newest unstable version did > > > not help. > > > > Hm, that's odd. Could you please take it upstream? [EMAIL PROTECTED] > > should probably be able to help you. > > > > > [blkid_probe_all_new taking _really long_] > > > > That's a bit odd, too. :-) > > > > > blk_id_probe_all_new seems to scan /proc/partitions and the do some > > > probeing on the devices? > > > > Mm. I take it you don't have any really weird devices attached that could be > > responsible for the slowdown? > > Not that I can think of. > However, I just upgraded the server to new hardware (faster cpu, > bigger disks) and the problem seems to be gone now... > I probably should try ltracing rpc.mountd to look at the execution > time of blk_id_probe_all_new again, just in case it's still > excessive, but the faster CPU might compensate for that. > > Hmm, no... Seems fine now: > 14:41:50.754679 blkid_probe_all_new(0x8063810, 0x805c940, 34, 17, > 0xf7ef4023) = 0 > 14:41:51.094040 __xstat64(3, "/home/ranma/mail", 0xffe7ef94) = 0 > > I also noticed that while I had upgraded nfs-kernel-server I was > still using an older version of libblkid1. Maybe that upgrade fixed > it. > > Anyway, I should be able to boot up the old components to do some > tests with them... Maybe it's a timing problem that only shows up > on slow CPUs? (PentiumIII 800MHz vs. Athlon64 3200+)
Unfortunately (or maybe fortunately ;)), while I did boot up the old parts I could not reproduce the problem again (during the short testing time). I also tried downgrading libblkid1 back to testing but it still worked flawlessly. -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
