Re: [PATCH] reiser4: fix readv
Hi Vladimir, this fixes a bunch of random user space oddities for me. Just patched 2.6.18-rc6-mm2 with this, and some annoyances I could not trace back to a change in user space just went bye-bye. Thanks a lot! Chris pgpJBZDdCOUrz.pgp Description: PGP signature
Re: [PATCH] reiser4: fix readv
On Thu, 14 Sep 2006 11:28:29 +0200, Christian Trefzer wrote: Hi Vladimir, this fixes a bunch of random user space oddities for me. Just patched 2.6.18-rc6-mm2 with this, and some annoyances I could not trace back to a change in user space just went bye-bye. Thanks a lot! Chris This does not patch against 2.6.17-3 patchset however. Any possibility this may be related to some startup issues as noted on other threads here? Thx -- Peter + Do not reply to this email, it is a spam trap and not monitored. I can be reached via this list, or via jabber: pete4abw at jabber.org ICQ: 73676357
Re: [PATCH] reiser4: fix readv
On Thu, Sep 14, 2006 at 10:35:02AM +, Peter wrote: This does not patch against 2.6.17-3 patchset however. Any possibility this may be related to some startup issues as noted on other threads here? I have seen the issues at bootup you noticed some time ago, but only once after the root fs had been mounted in a different way, i.e. laptop hdd stuffed into a USB case and connected to my desktop, mounted to /mnt/something. The most annoying problems that have been fixed for me were related to gentoo's postfix and spamd startup scripts. For some strange reason, they did not detect properly that postfix had been started / spamd had been stopped. Now everything seems kosher - I survived a few suspend/resume cycles without the hickups that have become common during the last few months. Sadly, I had more serious trouble to worry about, otherwise I had bugged the list myself : P Kind regards, Chris pgpgZzZU2mOck.pgp Description: PGP signature
Re: reiser4: mount -o remount,ro / causes error on reboot
On Sun, 10 Sep 2006 17:01:18 +, Peter wrote: this bug was also reported on gentoo wrt the newer baselayout. Indications are it may be a r4 issue, although no one seems to know why! http://bugs.gentoo.org/show_bug.cgi?id=144093 -- Peter + Do not reply to this email, it is a spam trap and not monitored. I can be reached via this list, or via jabber: pete4abw at jabber.org ICQ: 73676357
Re: [PATCH] reiser4: fix readv
Hello On Thursday 14 September 2006 14:35, Peter wrote: On Thu, 14 Sep 2006 11:28:29 +0200, Christian Trefzer wrote: Hi Vladimir, this fixes a bunch of random user space oddities for me. Just patched 2.6.18-rc6-mm2 with this, and some annoyances I could not trace back to a change in user space just went bye-bye. Thanks a lot! Chris This does not patch against 2.6.17-3 patchset however. 2.6.17-3 does not have the problem which that patch fixes. So you do not need it. Any possibility this may be related to some startup issues as noted on other threads here? no. Thx
Re: argh! it's reiserfs deadlocking! [was: Re: JFS - real deadlock and lockdep warning (2.6.18-rc5-mm1)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mattia Dongili wrote: On Wed, Sep 06, 2006 at 05:00:28PM -0500, Dave Kleikamp wrote: I meant to reply to this earlier. I've had a lot of distractions. On Tue, 2006-09-05 at 22:33 +0200, Mattia Dongili wrote: Hello, as the subject says it's some time[0] I'm experiencing deadlocks[1] (I'm only tracking -mm, and sporadically using the stable series). I have a couple of use cases that seem to reliably trigger the deadlock, namely using Eclipse and Firefox. [...] /dev/hda1 on / type reiserfs (rw) /dev/hda3 on /usr type reiserfs (rw) /dev/hda5 on /home type jfs (rw) bootlog: http://oioio.altervista.org/linux/dmesg-2.6.18-rc5-mm1-lockdep config: http://oioio.altervista.org/linux/config-2.6.18-rc5-mm1-lockdep Dave, I have to apologize. Reiser3 seem to be the one deadlocking here actually. Changing /home to reiser4 still deadlocks. Now, reiserfs-developers: would you want me to keep the filesystem around to try to test patches or potential fixes or can I wipe it out? The good thing is that the deadlock is 100% repeatable, the bad thing is that this laptop has a broken cdrom and I have to take the drive out and fsck it via usb1.1 each time. :) Thanks How is it that you arrived on reiser3 and reiser4 deadlocking here? - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFCVxYLPWxlyuTD7IRArZ1AJ9pJPRw0ERLLS36xhn6dyHiXZJtVgCeN+Xe OVBhxH0xk8UL/YaUKlHJuEE= =9R9c -END PGP SIGNATURE-
Re: Relocating files for faster boot/start-up on reiser(fs/4)
SCO has done this solution, thats why its such a dog. Peter wrote: On Wed, 13 Sep 2006 14:51:39 -0600, Quinn Harris wrote: Thoughts? Yes. Why on earth would you do this? By copying the files and renaming and hardlinking them is nothing a sysadmin would ever do. Just by copying you are allowing reiser to optimize the dir. You're trying to duplicate what a tree-based design does automatically. Moreover, remember that reiser packs files into clusters so that you may read more than just your one file from time to time which could end up adding time to your test. If reiser needs speedup it certainly won't be done by renaming files! JM$0.02 -- Curtis Maurand Senior Network Systems Engineer BlueTarp Financial, Inc. 443 Congress St. 6th Floor Portland, ME 04101 207.797.5900 x233 (office) 207.797.3833 (fax) mailto:[EMAIL PROTECTED] http://www.bluetarp.com
a bit OT: traditional Unix filesystems
Hi, I have a small OT query on working of traditional filesystem of Unix. Can someone comment/correct me on the query below? If i type $ cat /tmp/payal.txt (according to my knowledge) inode of / is found out (2) from super-block. From there physical location of / is read (i.e. the directory entry) and from there inode of tmp is found out. Then directory entry of tmp is read and inode of payal.txt is found out and then data blocks of that file are read. Am I correct in this? Now if tmp is on different partition or harddisk, how will directory entry of ? point it out exactly? As far as I know, directory entry contains names and inode number and not the device details, then how does it exactly work? I googled a lot for it, but didn't find exact answer. Can someone please explain? With warm regards, -Payal
Re: a bit OT: traditional Unix filesystems
Hi, On Thu, 14 Sep 2006 13:05:44 -0400, Payal Rathod wrote: Hi, I have a small OT query on working of traditional filesystem of Unix. Can someone comment/correct me on the query below? If i type $ cat /tmp/payal.txt (according to my knowledge) [...] [unverified by me, and unrelated] Now if tmp is on different partition or harddisk, how will directory entry of ? point it out exactly? The kernel has a list of mountpoints (see /proc/pid/mounts) per process. It looks there if path argument starts with one of those, and if so, passes the path on to the topmost filesystem handler for that mountpoint (it also knows the device, it is part of the mountpoint list). As far as I know, directory entry contains names and inode number and not the device details, then how does it exactly work? For mountpoints, the kernel checks the mountpoint table (in kernel memory, per process) before passing the request on to the (topmost) filesystem that handles that prefix (which reads the directory entry and fetches the inode mentioned there). cheers, Danny
Re: Relocating files for faster boot/start-up on reiser(fs/4)
On 14-Sep-06, at 6:23 PM, David Masover wrote: Quinn Harris wrote: On Thursday 14 September 2006 13:55, David Masover wrote: ... That is a good point. Recording the disk layout before and after to compare relative fragmentation would be a good idea. As well as randomizing the sequence as a sanity check. Also note that during boot I was using readahead on all 3885 files. So the kernel has a good opportunity to rearrange the reads. And the read sequence doesn't necessary match the order its needed (though I tried to get that). Speaking of which, did you parallize the boot process at all? Just off the top of my head, wouldn't that make the access sequence asynchronous thereby less predictable? (Although I'm sure it's a net win.) I'd estimate my system easily spent more than 50% of its boot time not touching the disk at all before I did that. Gentoo can do this, I'm not sure what else, as it kind of needs your init system to understand dependencies. ...
