[reiserfs-list] Cannot mount: device in use
Hello, just had a power outage in my area and when my system came back up, all my lvm'd reiserfs volumes reported that they were already mounted, even though they were not. I have seen this several times after system crashes and each time, the only way to resolve the problem is to login in single-user mode, umount the device (which reports device: not mounted) and then reboot... after that, the devices go through the journal replay as expected. As I do not have any lvm'd ext2fs, I will shortly create a small one, crash the system, and see if the problem happens with the lvm'd ext2fs or not, but until that time, here're my specifics: linux 2.2.19 reiserfs 3.5.32 lvm 0.9.1beta7 Also, someone previously asked if my mnttab file or /proc/mounts might have been the issue, so in rcS i had it copy them elsewhere before it removed the mnttab and started trying to mount filesystems... /proc/mounts only showed /dev/root on / and procfs on /proc... mnttab didn't have the external volumes in them either. Thanks. -- Scott Denton [EMAIL PROTECTED]
Re: [reiserfs-list] license question
Philip R. Auld wrote: Hi folks, I noticed recently that a good number of the files in the reiserfsprogs-3.x.0j contain only a Copyright Hans Reiser with no reference to the README file that puts them under the GPL. Are these files intentionally non-GPLed or is this an oversight? Here are the files in question: ./version.h: * Copyright 2000 Hans Reiser ./include/misc.h: * Copyright 1996-2000 Hans Reiser ./lib/misc.c: * Copyright 1996, 1997, 1998 Hans Reiser ./fsck/main.c: * Copyright 1996-2000 Hans Reiser ./fsck/pass0.c: * Copyright 1996-2001 Hans Reiser ./fsck/pass1.c: * Copyright 1996-1999 Hans Reiser ./fsck/pass2.c: * Copyright 1996-2001 Hans Reiser ./fsck/semantic.c: * Copyright 1996-1999 Hans Reiser ./fsck/pass4.c: * Copyright 1996, 1997, 1998 Hans Reiser ./fsck/lost+found.c: * Copyright 2000-2001 Hans Reiser ./fsck/ubitmap.c: * Copyright 1996-1999 Hans Reiser ./fsck/uobjectid.c: * Copyright 1996-2001 Hans Reiser ./fsck/ustree.c: * Copyright 1996-2001 Hans Reiser ./fsck/ufile.c: * Copyright 1996, 1997, 1998 Hans Reiser ./fsck/check.c: * Copyright 1996, 1997 Hans Reiser ./fsck/check_tree.c: * Copyright 1999 Hans Reiser ./fsck/journal.c: * Copyright 2000 Hans Reiser ./fsck/info.c: * Copyright 1996-1999 Hans Reiser ./fsck/segments.c: * Copyright 1998 Hans Reiser ./fsck/fsck.h: * Copyright 1996-2001 Hans Reiser Thanks for the help, Phil -- Philip R. Auld, Ph.D. Technical Staff Egenera Corp.[EMAIL PROTECTED] 165 Forest St, Marlboro, MA 01752(508)786-9444 Definitely an oversite. Thanks for spotting it. monstr, fix it. Hans
Re: [reiserfs-list] CPU useage of ReiserFS
On Sat, Jun 30, 2001 at 08:29:04PM +0200, Jens Benecke wrote: Hi, I just had a, er, 'lively' discussion with someone claiming ReiserFS is crap because it hogs even the fastest CPU too much, and it uses 4x as much processing power to do metadata operations, and in general is slower because of the journal. My benchmarks don't reflect this, especially on current hardware (ATA-66 and ATA-100 disks on VIA chipsets). While I agree that the journal does create an additional overhead, I'd like to know if the CPU overhead is really that much. I've seen your benchmarks on the web site but they don't say anything about CPU useage. Here's what happens when I rm a big directory tree on ext2 and reiserfs: ext2 -- Disk trashes like mad. Forget accessing it while rm is running. CPU usage is relatively low. Reiserfs -- Light disk accesses with little seeking (can barely hear it, LED blinks softly). Can do light jobs on the disk while rm is running. CPU usage hovers between 65% and 95%. OK, all those B* trees suck CPU cycles, and the journal means overhead, but in my humble opinion it's worth it. Even with the CPU hogging, most IO operations seem snappier to me on Reiserfs (at least compared to ext2, can't say about XFS or JFS). And I'm not even talking of the more efficient file packing. You makes your choices, you lives with it ;) Jean-Francois Landry -- In short, just as the Multics mentality of careful access controls shows up throughout Unix, the cretinous CP/M mentality of uncontrolled havoc shows up in DOS and all its mutant children. --- Tom Christiansen --
Re: [reiserfs-list] CPU useage of ReiserFS
On Sat, Jun 30, 2001 at 06:25:18PM -0400, Jean-Francois Landry wrote: On Sat, Jun 30, 2001 at 08:29:04PM +0200, Jens Benecke wrote: I just had a, er, 'lively' discussion with someone claiming ReiserFS is crap because it hogs even the fastest CPU too much, and it uses 4x as much processing power to do metadata operations, and in general is slower because of the journal. My benchmarks don't reflect this, especially on current hardware (ATA-66 and ATA-100 disks on VIA chipsets). it's not that important in many (most?) situations that require fast file I/O. the CPU in most I/O bound applications sits idle waiting for the disk. probably the only place where it would really matter would be in a beowulf style cluster or rendering farm. it's rare for any application to do a lot of I/O *and* a lot of computation. image files are huge, so a render-farm would be better off using XFS than reiserfs anyway - all benchmarks i've seen (including my own bonnie runs[1]) show that XFS is faster for large files, while reiserfs is much faster for lots of little files. overall, reiserfs is faster, but XFS uses less CPU. for applications that are primarily CPU-bound, it probably doesn't make much difference what file-system is used. for applications that are primarily IO-bound, the best filesystem to use depends on the nature of the application. in any case, you have to carefully benchmark all the available filesystems and weigh up the pros and cons until you've found the one that works best with your application. saying that reiserfs is best, or xfs is best, or foo-fs is best, is just plain silly - every fs has advantages and disadvantages. e.g. i'd use reiserfs for a mail queue fs or a news spool or Maildir/ style mail spools. for a mail spool with large mbox files, i'd use XFS. if i had to choose one or the other, i'd probably choose reiserfs...although it's a difficult choice: reiserfs wins overall on performance, but XFS has had several years more debugging in real-world conditions (on SGI's IRIX) i guess all this is a long way of saying facts and figures are relevant, but unsupported opinion counts for nothing. [1] my preliminary benchmark results are at: http://siva.taz.net.au/~cas/x-vs-r.html this is only a benchmark of a single IBM 40GB drive. I bought a pair of these and had intended to also benchmark a software RAID-0 setup, but one of the drives was faulty when it arrived (DMA and BAD CRC errors). i'll do another bonnie run when the replacement arrives. OK, all those B* trees suck CPU cycles, and the journal means overhead, but in my humble opinion it's worth it. Even with the CPU hogging, most IO operations seem snappier to me on Reiserfs (at least compared to ext2, can't say about XFS or JFS). And I'm not even talking of the more efficient file packing. You makes your choices, you lives with it ;) yep. craig -- Craig Sanders Systems Administrator VICNET- Victoria's Network http://www.vicnet.net.au/
[reiserfs-list] Reiserfs usage of get_hash_table()
Hi, I was taking a look at reiserfs code on 2.4.5 and I found out something which may be hurting performance quite badly. There are quite a few places using get_hash_table() in the code without calling touch_buffer() for the (possibly) found buffer_head. The touch_buffer(bh) call will set the referenced bit on bh-b_page, which is what informs the VM subsystem about the page usage.
[reiserfs-list] Quota?
Hey I got a patch called bigpatch-2.4.5.diff. I was wondering how I use it. It was supposed to be 3 patches in one. Thanks.
