Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Chris Mason wrote: > > On Monday, February 12, 2001 11:42:38 PM +0300 Hans Reiser > <[EMAIL PROTECTED]> wrote: > > >> Chris, > >> > >> Do you know if the people reporting the corruption with reiserfs on > >> 2.4 were using IDE drives with PIO mode and IDE multicount turned on? > >> > >> If so, it may be caused by the problem fixed by Russell King on > >> 2.4.2-pre2. > >> > >> Without his fix, I was able to corrupt ext2 while using PIO+multicount > >> very very easily. > > > > I suspect the bugfixes in pre2 will fix some of the more exotic corruption > reports we've seen, but this one (nulls in log files) probably isn't caused > by a random (or semi-random) lower layer corruption. These users are not > seeing random metadata corruption, so I suspect this bug is different (and > reiserfs specific). > > > Was the bug you describe also present in the 2.2.* series? If not, then > > the bugs are not the same. > > > > In 2.2 code the only data file corruption I know if is caused by a crash > > -chris Chris, your quoting is very confusing above. but I get your very interesting remark (thanks for noticing) that the nulls are specific to crashes on 2.2, and therefor could be due to the elevator bug on 2.4. It even makes rough sense that the elevator bug (said to occasionally cause a premature write of the wrong buffer) could cause an effect similar to a crash. I hope it is true, let's ask all users to upgrade to pre2 (a good idea anyway) and see if it cures. zam is perhaps very clever for deferring working on this bug..:-) Hans - 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://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Chris Mason wrote: > > On Monday, February 12, 2001 11:42:38 PM +0300 Hans Reiser > <[EMAIL PROTECTED]> wrote: > > >> Chris, > >> > >> Do you know if the people reporting the corruption with reiserfs on > >> 2.4 were using IDE drives with PIO mode and IDE multicount turned on? > >> > >> If so, it may be caused by the problem fixed by Russell King on > >> 2.4.2-pre2. > >> > >> Without his fix, I was able to corrupt ext2 while using PIO+multicount > >> very very easily. > > > > I suspect the bugfixes in pre2 will fix some of the more exotic corruption > reports we've seen, but this one (nulls in log files) probably isn't caused > by a random (or semi-random) lower layer corruption. These users are not > seeing random metadata corruption, so I suspect this bug is different (and > reiserfs specific). > > > Was the bug you describe also present in the 2.2.* series? If not, then > > the bugs are not the same. > > > > In 2.2 code the only data file corruption I know if is caused by a crash > > -chris I'd like to announce on our website and mailing list that all XXX users should upgrade to 2.4.2pre2. Do you all agree with this? What is the exact definition of XXX? Hans - 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://vger.kernel.org/lkml/
What is 2.4 Linux networking performance like compared to BSD?
I have a client that wants to implement a webcache, but is very leery of implementing it on Linux rather than BSD. They know that iMimic's polymix performance on Linux 2.2.* is half what it is on BSD. Has the Linux 2.4 networking code caught up to BSD? Can I tell them not to worry about the Linux networking code strangling their webcache product's performance, or not? Hans - 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/
Re: What is 2.4 Linux networking performance like compared to BSD?
Todd wrote: > > hans, > > we've found that the TCP and UDP performance on 2.4 is *dramatically* > better than 2.2. with the acenic gig-e driver on PIII-933 UP (66MHz x > 64bits PCI) we are getting 993 Mb/s with 2.4.0 with jumbo frames (about > 850 Mb/s with standard ethernet frames). the best number we got with 2.2 > was about 650 with jumbos and 550 with standard. > > i'd recommend it's networking performance to anyone. > > todd underwood > [EMAIL PROTECTED] > > On Thu, 1 Mar 2001, Hans Reiser wrote: > > > Date: Thu, 01 Mar 2001 02:26:20 +0300 > > From: Hans Reiser <[EMAIL PROTECTED]> > > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > Subject: What is 2.4 Linux networking performance like compared to BSD? > > > > I have a client that wants to implement a webcache, but is very leery of > > implementing it on Linux rather than BSD. > > > > They know that iMimic's polymix performance on Linux 2.2.* is half what it is on > > BSD. Has the Linux 2.4 networking code caught up to BSD? > > > > Can I tell them not to worry about the Linux networking code strangling their > > webcache product's performance, or not? > > > > Hans > > - > > 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/ > > The problem is that I really need BSD vs. Linux experiences, not Linux 2.4 vs. 2.2 experiences, because the webcache industry tends to strongly disparage Linux networking code, so much better isn't necessarily good enough. Hans - 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/
Re: What is 2.4 Linux networking performance like compared to BSD?
Nathan Dabney wrote: > > On Thu, Mar 01, 2001 at 07:03:31PM +0300, Hans Reiser wrote: > > The problem is that I really need BSD vs. Linux experiences, not Linux 2.4 vs. > > 2.2 experiences, because the webcache industry tends to strongly disparage Linux > > networking code, so much better isn't necessarily good enough. > > > > Hans > > Check with the www.swelltech.com people, they should have the info you need. > > http://www.swelltech.com/pengies/joe/squidtuneup/t1.html > > The above link contains some decent squid performance hints for 2.2+Squid. > > -Nathan Dabney It does not say anything about BSD vs. Linux 2.4 networking code. If I can't get information about BSD v. Linux 2.4 networking code, then reiserfs has to get ported to BSD which will be both nice and a pain to do. Hans - 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/
Re: What is 2.4 Linux networking performance like compared to BSD?
James Lewis Nance wrote: > > On Thu, Mar 01, 2001 at 02:26:20AM +0300, Hans Reiser wrote: > > I have a client that wants to implement a webcache, but is very leery of > > implementing it on Linux rather than BSD. > > > > They know that iMimic's polymix performance on Linux 2.2.* is half what it > > is on BSD. Has the Linux 2.4 networking code caught up to BSD? > > > > Can I tell them not to worry about the Linux networking code strangling their > > webcache product's performance, or not? > > Hi Hans, > I dont have an answer for you, but it would be nice to know the answer. > Would it be difficult to measure this? It should not be difficult to make > a machine dual boot Linux and BSD, and then we can measure the differences. > If there is a significant performance difference either way then we can > try and investigate it to see why. > > Thanks, > > Jim This is indeed what we should do if we get no answer from the list by someone who has already done such work. Hans - 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/
Re: What is 2.4 Linux networking performance like compared to BSD?
Tigran Aivazian wrote: > > On Thu, 1 Mar 2001, Hans Reiser wrote: > > > > This is indeed what we should do if we get no answer from the list by someone > > who has already done such work. > > > > Hans, > > exactly what you want to measure? I have UP, 2way-SMP and 4way-SMP > machines all of which have at least Linux+FreeBSD installed. All my tests > so far (e.g. comparing NFS servers or filesystems etc) showed Linux (2.4) > to be a lot faster than FreeBSD in all areas. However, to get specific > answers you need to ask specific questions. Ask and you shall receive. > > (things like SPEC SFS results I can't tell because it is illegal (without > going through proper steps of publishing them), I shouldn't even be saying > that they show Linux to be much faster :) > > Regards, > Tigran Thanks Tigan, you helped me move the client past the Linux vs. BSD issue. Hans - 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/
Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)
Chris Mason wrote:
>
> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
> >>> EIP; c013f911<=
> > Trace; c013f706
> > Trace; c0136e01
> >
>
> Here is a patch against our 2.4 code (3.6.25) that does the
> same as the patch posted for 3.5.29:
>
> -chris
>
> --- linux/include/linux/reiserfs_fs.h.1 Tue Jan 9 21:22:27 2001
> +++ linux/include/linux/reiserfs_fs.h Tue Jan 9 21:22:55 2001
> @@ -926,8 +926,7 @@
> //((block_size - BLKH_SIZE - IH_SIZE - DEH_SIZE * 2) / 2)
>
> // two entries per block (at least)
> -#define REISERFS_MAX_NAME_LEN(block_size) \
> -((block_size - BLKH_SIZE - IH_SIZE - DEH_SIZE))
> +#define REISERFS_MAX_NAME_LEN(block_size) 255
>
>
>
> --- linux/fs/reiserfs/dir.c.1 Tue Jan 9 21:22:19 2001
> +++ linux/fs/reiserfs/dir.c Tue Jan 9 21:21:02 2001
> @@ -142,6 +142,10 @@
> if (!d_name[d_reclen - 1])
> d_reclen = strlen (d_name);
>
> + if (d_reclen > REISERFS_MAX_NAME_LEN(inode->i_sb->s_blocksize)){
> + /* too big to send back to VFS */
> + continue ;
> + }
> d_off = deh_offset (deh);
> filp->f_pos = d_off ;
> d_ino = deh_objectid (deh);
I think that in the short term, so as to make it easier to merge us into 2.4, it is
reasonable to
restrict us to small names, so go ahead and merge this code into cvs if not done
already.
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Don't mix reiserfs and RAID5 in linux-2.4.1-pre8, severe corruption
Edward wrote: > > Reiserfs in linux-2.4.1-pre8 does not properly with the RAID5 code that > is in that kernel. It is easy to get corrupted filesystem on device in > less than 1 minute. Please, do not use it (reiserfs) on RAID5 devices. > We are trying to figure out what is wrong. > > Edward There is a report that it is not just reiserfs that has the corruption problem. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] - filesystem corruption on soft RAID5 in 2.4.0+
We'll test and get back to you.
Hans
Neil Brown wrote:
>
> There have been assorted reports of filesystem corruption on raid5 in
> 2.4.0, and I have finally got a patch - see below.
> I don't know if it addresses everybody's problems, but it fixed a very
> really problem that is very reproducable.
>
> The problem is that parity can be calculated wrongly when doing a
> read-modify-write update cycle. If you have a fully functional, you
> wont notice this problem as the parity block is never used to return
> data. But if you have a degraded array, you will get corruption very
> quickly.
> So I think this will solve the reported corruption with ext2fs, as I
> think they were mostly on degradred arrays. I have no idea whether it
> will address the reiserfs problems as I don't think anybody reporting
> those problems described their array.
>
> In any case, please apply, and let me know of any further problems.
>
> --- ./drivers/md/raid5.c2001/01/21 04:01:57 1.1
> +++ ./drivers/md/raid5.c2001/01/21 20:36:05 1.2
> @@ -714,6 +714,11 @@
> break;
> }
> spin_unlock_irq(&conf->device_lock);
> + if (count>1) {
> + xor_block(count, bh_ptr);
> + count = 1;
> + }
> +
> for (i = disks; i--;)
> if (chosen[i]) {
> struct buffer_head *bh = sh->bh_cache[i];
>
> From my notes for this patch:
>
>For the read-modify-write cycle, we need to calculate the xor of a
>bunch of old blocks and bunch of new versions of those blocks. The
>old and new blocks occupy the same buffer space, and because xoring
>is delayed until we have lots of buffers, it could get delayed too
>much and parity doesn't get calculated until after data had been
>over-written.
>
>This patch flushes any pending xor's before copying over old buffers.
>
> Everybody running raid5 on 2.4.0 or 2.4.1-pre really should apply this
> patch, and then arrange the get parity checked and corrected on their
> array.
> There currently isn't a clean way to correct parity.
> One way would be to shut down to single user, remount all filesystems
> readonly, or un mount them, and the pull the plug.
> On reboot, raid will rebuild parity, but the filesystems should be
> clean.
> An alternate it so rerun mkraid giving exactly the write configuration.
> This doesn't require pulling the plug, but if you get the config file
> wrong, you could loose your data.
>
> NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
I really think Rik has it right here. In particular, an MP3 player needs to be able to say, I have X milliseconds of buffer so make my worst case latency X milliseconds. The number of requests is the wrong metric, because the time required per request depends on disk geometry, disk caching, etc. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: elevator code
If I understand your elevator algorithm, you switch between two queues, filling one queue while removing from another queue. If you modify this to only be invoked when starvation of is detected, that is, to only prevent filling the removing queue when the oldest unsatisfied request exceeds some tunable age, then I like the model for those situations where real time I/O is not needed. We also need some functionality that gives priority to a process that has I/O that has been pending for more than that process has stated its maximum pending I/O time is, and this does not address that issue. Unfortunately the guy I hired to do these features for us didn't write code with sufficient care for me to keep him with us, so I am again looking for that hire to do it. Maybe somebody will beat Namesys to it, and do these things for us, which is okay with me. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
(reiserfs) Re: More on 2.2.18pre2aa2 (summary of elevator ideas)
"Jeff V. Merkey" wrote: > > One important point on remirroring I did not mention in my post. In > NetWare, remirroring scans the disk BACKWARDS (n0) to prevent > artificial starvation while remirring is going on. This was another > optimization we learned the hard way by trying numerous approaches to > the problem. > > Jeff Interesting. Thanks Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: More on 2.2.18pre2aa2
Ragnar Kjørstad wrote: > > On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote: > > If I may ask a potentially stupid question, how can request latency be > > anything but a factor of time? Latency is how /long/ you (or the computer) > > /waits/ for something. That defines it as a function of time. > > Latency is of course a factor of time, but the point is that the > acceptable latency differs from device to device. For a slower device > longer latency must be acceptable, and if the relationship is linear, > then using number of requests may be a simpler and better way of doing > it. > Latency is a function of time, but the units of time need not be seconds and could be requests. In theory. In this particular case, measuring time in units of requests is inappropriate. We have a choice between having users (or device driver authors for the defaults) estimate how many milliseconds is reasonable for a given device, or having them estimate how many requests can be guaranteed to not exceed the time they can wait for a particular device. I would rather take responsibility for knowing not to get unreasonable in the smallness of my MP3 buffering for a floppy device experiencing multiple processes accessing it for reasons of performance effects being disastrous than take responsibility for estimating how many requests will not add up to more than X milliseconds of buffer on my hard drive. Number of requests is irrelevant to realtime I/O scheduling, seconds are relevant to realtime I/O scheduling. There are two problems to be solved: fairness, and realtime I/O scheduling. Fairness can be handled effectively by measuring time in units of requests. Guaranteeing maximum latencies requires traditional time units. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs) Re: An elevator algorithm
I think Xuan's algorithm is good, so I want to add to it.:-) Ragnar, I don't understand your objection to it. It is always the case that if you specify real time constraints that are impossible then they aren't met. If you want to get fancy you could sort all expired time limit requests by blocknr. This gives you three lists: one list containing unexpired requests sorted by blocknr, another list containing unexpired requests sorted by time, and a third containing expired requests sorted by blocknr. Throw in Andrea's/Netware's optimization objective, and you could have four lists: list 1 contains unexpired requests sorted by blocknr, list 2 contains unexpired requests sorted by time until expiry, lists 3a and 3b if not empty contain expired requests and are alternating queues in which one list is being fulfilled and the other list is being added to at any given time, with the the queues switching roles whenever the list being fulfilled becomes empty. I like this model, and it probably isn't hard to code. Maybe I can talk Xuan into giving it a try?:-) Hans Ragnar Kjørstad wrote: > > On Sat, Sep 16, 2000 at 01:17:53PM +0200, Xuan Baldauf wrote: > > I'm not a kernel hacker (and therefore I'm not familiar with the kernel > > terminology), and maybe this idea is already old, but here is an > > algorithm for an elevator which tries to guarantee smoothness and no > > stalling: > > > > Every rw-request gets an expiry timeout (e.g. in jiffies) where it's > > completion must have started. Every request is member of two sorted > > lists which support fast add|remove and iterating to the previous|next > > member (linked list, binary tree, etc.): > > The request list sorted by expiry and the request list sorted by block > > number. When a rw-access is requested, the request gets its timeout and > > is inserted in those two lists. The elevator has a current request on > > which it is working. When the elevator is finished, it removes the > > current request from the two lists and gets the "current time" (in > > jiffies). If the head of the request list sorted by expiry has a time > > equal to or smaller than the current time, the elevator continues with > > that request. Else it continues with the next or previous request in the > > list sorted by block number. (It can decide which direction, wether to > > continue with the old direction or wether to always start with a > > definite direction) > > > > This way, you have good elevator characteristics while being somewhat > > able to guarantee maximum request duration. If the timeout expired, the > > requested block is served immediately. Only when the system is > > overloaded, so that the difference between the current time and the > > oldest expiry timout exceeds a given maximum, the elevator fails. In > > this case, the system should be throttled (inserting new requests should > > block), I think. Users could determine the expiry-timeouts so that > > important applications get shorter timeouts while not-so-important > > applications which can wait can request a longer timeout. > > > > This algorithm is, of course, only per low-level-device. > > > > What do you think? > > If the load is to high to serve requests within the time-limit, the > elevator-code will stop working, and everything will slow down. > > You should not serve a request imidiately when it's too old (because the > requests supposed to be served first according to the elevator is likely > to become too old soon, and then you only add more seeking), but only > stop inserting new requests before it. > > If I understand the current code correctly, it works like this: > > Current queue: > > 02:04:05:06:09:15 # sector to be written to > 05:03:02:04:00:01 # request-nr > > In this example the "timeout" is 5 requests, so a new request can never > be placed before a existing request with request-nr < new-request-nr-5; > > One request is served (from the head of the queue) and a request to > sector 3 is added: > > 04:05:06:09:03:15 # sector to be written to > 03:02:04:00:06:01 # request-nr > > One request is served (from the head of the queue) and a request to > sector 2 is added: > > 05:06:09:03:15:02 # sector to be written to > 02:04:00:06:01:07 # request-nr > > One request is served (from the head of the queue) and a request to > sector 16 is added: > > 06:09:03:15:02:16 # sector to be written to > 04:00:06:01:07:08 # request-nr > > So we've ended up with a very silly queue > > Now, the description of the algorithm said that there was a number > within each request that was declined by one whenever a new request > passed it in the queue. This will never be used after it becomes > negative, so it would be the same to decline the number of all the > requests by 1, right? And comparing this changing number to 0 is the > same as comparing request-numbers, only more work, right? So I assume I > didn't understand the algorithm correctly :) > > Now, lets do the same test with
Re: panic in reiserfs on test-2.4.0-test9/10
We'll try to reproduce this when the guys get in for work this morning, thanks for the bug report. Elena, add symlink testing to mongo.sh so that it gets tested by our regression tests. Hans Andy Robinson wrote: > > Hi, > > I tried the linux-2.4.0-test9-resiserfs-3.6.18-patch on both 2.4.0-test9 > and test2.4.0-test10 > and got the following PANIC I originally saw this PANIC when doing a 'cp > -a / /reiserfs'. > I narrowed it done to a simple symlink > > Andy > > [root@client19 /reiserfs]# ln -s foo.tar foo > Unable to handle kernel NULL pointer dereference at virtual address > 0010 > printing eip: > c0185953 > *pde = > Oops: > CPU:0 > EIP:0010:[] > EFLAGS: 00010296 > eax: c12a017c ebx: c12a0060 ecx: 000f edx: > esi: c12a0090 edi: c12a ebp: 0005 esp: c0c01b60 > ds: 0018 es: 0018 ss: 0018 > Process ln (pid: 928, stackpage=c0c01000) > Stack: c12a0078 c12a017c c0c01bf8 0001 c0c01be0 c0178dc4 > c058dc00 >c0c01ba4 c0c01b8c c0182728 c0182736 0001 0130 > > c0c01c40 0001 c0c01c28 c0c01bfc > > Call Trace: [] [] [] [] > [] [] [] >[] [] [] [] [] > Code: 8b 52 10 ff d2 5b 5f 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02 > Segmentation fault > > ksymoops 2.3.4 on i686 2.4.0-test9. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.0-test9/ (default) > -m /boot/System.map-test9 (specified) > > No modules in ksyms, skipping objects > Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid > lsmod file? > Unable to handle kernel NULL pointer dereference at virtual address > 0010 > c0185953 > *pde = > Oops: > CPU:0 > EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010296 > eax: c12a017c ebx: c12a0060 ecx: 000f edx: > esi: c12a0090 edi: c12a ebp: 0005 esp: c0c01b60 > ds: 0018 es: 0018 ss: 0018 > Process ln (pid: 928, stackpage=c0c01000) > Stack: c12a0078 c12a017c c0c01bf8 0001 c0c01be0 c0178dc4 > c058dc00 >c0c01ba4 c0c01b8c c0182728 c0182736 0001 0130 > > c0c01c40 0001 c0c01c28 c0c01bfc > > Call Trace: [] [] [] [] > [] [] [] >[] [] [] [] [] > Code: 8b 52 10 ff d2 5b 5f 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02 > > >>EIP; c0185953<= > Trace; c0178dc4 > Trace; c0182728 > Trace; c0182736 > Trace; c018ede7 > Trace; c017d3a3 > Trace; c017d842 > Trace; c017a5f2 > Trace; c0230f99 > Trace; c0239e3a > Trace; c0139892 > Trace; c0139951 > Trace; c010a717 > Code; c0185953 > <_EIP>: > Code; c0185953<= >0: 8b 52 10 mov0x10(%edx),%edx <= > Code; c0185956 >3: ff d2 call *%edx > Code; c0185958 >5: 5bpop%ebx > Code; c0185959 >6: 5fpop%edi > Code; c018595a >7: 8b 54 24 14 mov0x14(%esp,1),%edx > Code; c018595e >b: 8b 42 34 mov0x34(%edx),%eax > Code; c0185961 >e: 89 c7 mov%eax,%edi > Code; c0185963 > 10: 0f b7 47 02 movzwl 0x2(%edi),%eax > > 1 warning issued. Results may not be reliable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: panic in reiserfs: _get_block_create_0 gets bh_result->b_data = NULL
Thanks for the bug report, we'll investigate. Hans Tigran Aivazian wrote: > > Hi Hans, > > Simply starting the validation phase of SPEC SFS with NFS mounted reiserfs > filesystem panics as shown in the log below. A quick look at the source > suggests that _get_block_create_0() (and therefore, more generally, > reiserfs_get_block()) was passed a buffer head bh_result with ->b_data = > NULL. So, we panic at line 256 of fs/reiserfs/inode.c when doing: > > memset (bh_result->b_data, 0, inode->i_sb->s_blocksize) > > Is reiserfs supposed to be highmem-aware? I assume so. > > Regards, > Tigran > > root@hilbert:~# reiserfs: checking transaction log (device 08:11) ... > Using r5 hash to sort names > ReiserFS version 3.6.18 > > root@hilbert:~# free > total used free sharedbuffers cached > Mem: 6132516 3476405784876 0 74252 238984 > -/+ buffers/cache: 344046098112 > Swap: 1847432 01847432 > root@hilbert:~# Unable to handle kernel NULL pointer dereference at virtual address > > printing eip: > f88f9024 > *pde = 3731a001 > *pte = > > Entering kdb (current=0xf72ba000, pid 492) on processor 2 Panic: Oops > due to panic @ 0xf88f9024 > eax = 0x ebx = 0x0400 ecx = 0x0400 edx = 0x1000 > esi = 0xf2608228 edi = 0x esp = 0xf72bbb64 eip = 0xf88f9024 > ebp = 0xf72bbc20 xss = 0x0018 xcs = 0x0010 eflags = 0x00010246 > xds = 0x0018 xes = 0x0018 origeax = 0x ®s = 0xf72bbb30 > [2]kdb> ps > Task AddrPid Parent [*] cpu StateThread Command > 0xc7678000 0001 0 002 stop 0xc7678350 init > 0xc76e2000 0002 0001 0 003 stop 0xc76e2350 kswapd > 0xc76e 0003 0001 0 000 stop 0xc76e0350 kreclaimd > 0xc76de000 0004 0001 0 000 stop 0xc76de350 kflushd > 0xc76dc000 0005 0001 0 001 stop 0xc76dc350 kupdate > 0xf73b8000 0428 0001 0 001 stop 0xf73b8350 syslogd > 0xf734c000 0438 0001 1 000 run 0xf734c350 klogd > 0xf7304000 0453 0001 0 000 stop 0xf7304350 portmap > 0xf731 0471 0001 0 002 stop 0xf7310350 rpc.rquotad > 0xf7314000 0481 0001 0 002 stop 0xf7314350 rpc.mountd > 0xf7308000 0491 0001 1 003 run 0xf7308350 nfsd > 0xf72ba000 0492 0001 1 002 run 0xf72ba350*nfsd > 0xf72b6000 0493 0492 0 002 stop 0xf72b6350 lockd > 0xf72b4000 0494 0493 0 002 stop 0xf72b4350 rpciod > 0xf72ae000 0495 0001 0 002 stop 0xf72ae350 nfsd > 0xf72ac000 0496 0001 0 002 stop 0xf72ac350 nfsd > 0xf72a4000 0497 0001 0 002 stop 0xf72a4350 nfsd > 0xf729a000 0498 0001 0 002 stop 0xf729a350 nfsd > 0xf7298000 0499 0001 0 000 stop 0xf7298350 nfsd > 0xf728e000 0500 0001 0 002 stop 0xf728e350 nfsd > 0xf7328000 0515 0001 0 000 stop 0xf7328350 rpc.statd > 0xf7276000 0541 0001 0 003 stop 0xf7276350 xinetd > [2]more> > 0xf720e000 0582 0001 0 001 stop 0xf720e350 gpm > 0xf7204000 0597 0001 0 001 stop 0xf7204350 crond > 0xf754e000 0619 0001 0 001 stop 0xf754e350 mingetty > 0xf72e 0620 0001 0 001 stop 0xf72e0350 mingetty > 0xf7322000 0621 0001 0 000 stop 0xf7322350 mingetty > 0xf71f 0622 0001 0 001 stop 0xf71f0350 mingetty > 0xf71b4000 0623 0001 0 001 stop 0xf71b4350 login > 0xf7176000 0626 0623 0 001 stop 0xf7176350 bash > 0xf711 0683 0541 0 003 stop 0xf7110350 in.telnetd > 0xf710a000 0684 0683 0 000 stop 0xf710a350 login > 0xf70f2000 0685 0684 0 000 stop 0xf70f2350 bash > 0xf2606000 0720 0001 1 001 run 0xf2606350 kreiserfsd > 0xf2386000 0725 0541 0 003 stop 0xf2386350 in.telnetd > 0xf22e8000 0726 0725 0 003 stop 0xf22e8350 login > 0xf216a000 0727 0726 0 003 stop 0xf216a350 bash > [2]kdb> bt > EBP EIP Function(args) > 0xf72bbc20 0xf88f9024 [reiserfs]_get_block_create_0+0x258 (0xefc6c960, 0x0, >0xef511740, 0x4, 0x1) >reiserfs .text 0xf88f3060 0xf88f8dcc 0xf88f9264 > 0xf72bbdec 0xf88f955d [reiserfs]reiserfs_get_block+0x141 (0xefc6c960, 0x0, >0xef511740, 0x0) >reiserfs .text 0xf88f3060 0xf88f941c 0xf88fa5fc > 0xf72bbe6c 0xc013a592 block_read_full_page+0x11a (0xc73704f0, 0xf88f941c) >kernel .text 0xc010 0xc013a478 0xc013a740 > 0xf72bbe7c 0xf88fc16d [reiserfs]reiserfs_readpage+0x11 (0x0, 0xc73704f0) >reiserfs .text 0xf88f3060 0xf88fc15c 0xf88fc174 > 0xf72bbea0 0xc012c1ea read_cache_page+0x9a (0xefc6c9fc, 0x0, 0xf88fc15c, 0x0) >kernel .text 0xc010 0xc012c150 0xc012c2b4 > 0xf72bbebc 0xc0146369 page_getlink+0x21 (0xef983e40, 0xf72bbed8, 0xf72ba000) >
Re: (reiserfs) Re: An elevator algorithm
Ragnar Kjørstad wrote: > > On Fri, Sep 22, 2000 at 03:23:26PM -0700, Hans Reiser wrote: > > I think Xuan's algorithm is good, so I want to add to it.:-) > > > > Ragnar, I don't understand your objection to it. It is always the > > case that if you specify real > > time constraints that are impossible then they aren't met. > > My objection was that in the case where it is impossible to serve > requests within the maximum latency, it would stop ordering the > requests. > > With a FIFO queue, the throuput will be lower, and that will also > give longer latency. > > -- > Ragnar Ok, reasonable objection.:) Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[Fwd: [reiserfs-dev] [Fwd: [reiserfs-list] 2.4.3-pre1 oops w/ rsync & ReiserFS]]
David, did you determine if it was a memory bug? Just to note: stack trace doesn't involve reiserfs at all. Other people suggested that it may me memory bug. Nikita. Hans Reiser writes: > Who is taking this one? > > HansReturn-Path: <[EMAIL PROTECTED]> > Delivered-To: [EMAIL PROTECTED] > Received: (qmail 30581 invoked by uid 501); 19 Mar 2001 23:27:52 - > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Precedence: bulk > list-help: <mailto:[EMAIL PROTECTED]> > list-unsubscribe: <mailto:[EMAIL PROTECTED]> > list-post: <mailto:[EMAIL PROTECTED]> > Delivered-To: mailing list [EMAIL PROTECTED] > Received: (qmail 30574 invoked from network); 19 Mar 2001 23:27:52 - > Date: Mon, 19 Mar 2001 15:28:42 -0800 > From: David Raufeisen <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Reply-To: David Raufeisen <[EMAIL PROTECTED]> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > User-Agent: Mutt/1.3.12i > X-Operating-System: Linux 2.2.17 i686 > Subject: [reiserfs-list] 2.4.3-pre1 oops w/ rsync & ReiserFS > X-Mozilla-Status2: > > Getting oops every time I run rsync today.. happens after it receives file list and >is starting to stat all the files.. filesystem is reiser. > > Linux prototype 2.4.3-pre1 #2 Thu Mar 15 00:24:43 PST 2001 i686 unknown > > 15:25:28 up 1 day, 20:05, 4 users, load average: 0.00, 0.03, 0.00 > > Linux prototype 2.4.3-pre1 #2 Thu Mar 15 00:24:43 PST 2001 i686 unknown > > Gnu C 2.95.3 > Gnu make 3.79.1 > binutils 2.11.90.0.1 > util-linux 2.11a > modutils 2.4.2 > e2fsprogs 1.19 > reiserfsprogs 3.x.0b > Linux C Library2.2.2 > Dynamic linker (ldd) 2.2.2 > Procps 2.0.7 > Net-tools 1.59 > Kbdcommand > Sh-utils 2.0.11 > Modules Loaded NVdriver > > prototype:~# ksymoops oops.txt > ksymoops 2.3.7 on i686 2.4.3-pre1. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.3-pre1/ (default) > -m /System.map (default) > > Warning: You did not tell me where to find symbol information. I will > assume that the log matches the kernel and modules that are running > right now and I'll use the default options above for symbol resolution. > If the current kernel and/or modules do not match the log, you can get > more accurate output by telling me the kernel version and where to find > map, modules, ksyms etc. ksymoops -h explains the options. > > Unable to handle kernel paging request at virtual address 4280d8c4 > c01410c0 > *pde = > Oops: > CPU:0 > EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00210207 > eax: c7fdc5e0 ebx: 4280d8ac ecx: 000e edx: 21cd5a87 > esi: edi: c71424c0 ebp: 4280d8c4 esp: c37b1f04 > ds: 0018 es: 0018 ss: 0018 > Process rsync (pid: 16269, stackpage=c37b1000) > Stack: c37b1f68 c71424c0 c37b1fa4 c7fdc5e0 c5919022 21cd5a87 000a >c01392d0 c71424c0 c37b1f68 c37b1f68 c0139a92 c71424c0 c37b1f68 >c5919000 c37b1fa4 c5919000 c01390da 0008 > Call Trace: [] [] [] [] [] >[] [] > Code: 8b 6d 00 8b 54 24 18 39 53 48 75 7c 8b 44 24 24 39 43 0c 75 > > >>EIP; c01410c0<= > Trace; c01392d0 > Trace; c0139a92 > Trace; c01390da > Trace; c013a0dc <__user_walk+3c/60> > Trace; c0137116 > Trace; c012f453 > Trace; c0108e8b > Code; c01410c0 > <_EIP>: > Code; c01410c0<= >0: 8b 6d 00 mov0x0(%ebp),%ebp <= > Code; c01410c3 >3: 8b 54 24 18 mov0x18(%esp,1),%edx > Code; c01410c7 >7: 39 53 48 cmp%edx,0x48(%ebx) > Code; c01410ca >a: 75 7c jne88 <_EIP+0x88> c0141148 > Code; c01410cc >c: 8b 44 24 24 mov0x24(%esp,1),%eax > Code; c01410d0 > 10: 39 43 0c cmp%eax,0xc(%ebx) > Code; c01410d3 > 13: 75 00 jne15 <_EIP+0x15> c01410d5 > > > 1 warning issued. Results may not be reliable. > > > > -- > David Raufeisen <[EMAIL PROTECTED]> > Cell: (604) 818-3596 >
Re: [reiserfs-list] Re: ReiserFS - corrupted files (2.4.3)
monstr will debug this and elena will enter it into our buglist file.
Hans
Rasmus Bøg Hansen wrote:
>
> Hello
>
> I am getting musch the same types of corruption. I am on a K6-2 with a
> 30Gb IBM HD and 256Mb RAM running vanilla 2.4.3 with iptables and squid
> caching proxy. The problems arise on the cache part of the FS (i.e. with
> many file operations).
>
> I am considering using reiserfsck (3.x.0j) to fix it, but it has to wait
> until the morning - so in the meantime perhaps somebody can use the info
> about the corruptions? I have nowhere to back up my rather large (in
> comparison to other space on the box) cache, but if it goes lost in the
> process of rebuilding it, it does not matter so much.
>
> What should I do to help? I will try to debug the problem if necessary -
> should I turb on internal checks?
>
> On Mon, 2 Apr 2001, Robert NEDBAL wrote:
>
> > Hello,
> > I'm using ReiserFS on my primary filesystem and yesterday, I have found
> > that some files are corrupted. Yesterday I had to reset computer becase
> > X Window freezed. Maybe it caused this problem.
> >
> > This comes from log:
>
> [SNIP]
>
> My log goes much the same (although I have fewer errors - it seems to
> affect only few files):
> Mar 30 10:32:09 wiibroe kernel: reiserfs: checking transaction log
> (device 16:01) ...
> Mar 30 10:32:09 wiibroe kernel: Using r5 hash to sort names
> Mar 30 10:32:09 wiibroe kernel: ReiserFS version 3.6.25
> [...]
> Apr 2 14:36:10 wiibroe kernel: is_leaf: item location seems wrong:
> *OLD*[1214 319934 0x8f1 DIRECT], item_len 0, item_location 0,
> free_space(entry_count) 2289
> Apr 2 14:36:10 wiibroe kernel: vs-5150: search_by_key: invalid format
> found in block 132193. Fsck?
> Apr 2 14:36:10 wiibroe kernel: is_leaf: item location seems wrong:
> *OLD*[1214 319934 0x8f1 DIRECT], item_len 0, item_location 0,
> free_space(entry_count) 2289
> Apr 2 14:36:10 wiibroe kernel: vs-5150: search_by_key: invalid format
> found in block 132193. Fsck?
> Apr 2 14:36:10 wiibroe kernel: vs-13050: reiserfs_update_sd: i/o
> failure occurred trying to update [1214 319936 0x0 SD] stat datais_leaf:
> item location seems wrong: *OLD*[1214 319934 0x8f1 DIRECT], item_len 0,
> item_location 0, free_space(entry_count) 2289
> Apr 2 14:36:10 wiibroe kernel: vs-5150: search_by_key: invalid format
> found in block 132193. Fsck?
> Apr 2 14:36:10 wiibroe kernel: vs-: reiserfs_delete_solid_item: i/o
> failure occurred trying to delete [1214 319936 0x0 SD]
> [...]
> Apr 2 18:36:25 wiibroe kernel: vs-13042: reiserfs_read_inode2: [1020
> 271248 0x0 SD] not found
> Apr 2 18:36:25 wiibroe kernel: vs-13048: reiserfs_iget: bad_inode. Stat
> data of (1020 271248) not found
> Apr 2 18:36:50 wiibroe kernel: is_leaf: item location seems wrong:
> *OLD*[1214 319934 0x8f1 DIRECT], item_len 0, item_location 0,
> free_space(entry_count) 2289
> Apr 2 18:36:50 wiibroe kernel: vs-5150: search_by_key: invalid format
> found in block 132193. Fsck?
> Apr 2 18:36:50 wiibroe kernel: vs-13070: reiserfs_read_inode2: i/o
> failure occurred trying to find stat data of [1214 319935 0x0 SD]
> Apr 2 18:36:50 wiibroe kernel: vs-13048: reiserfs_iget: bad_inode. Stat
> data of (1214 319935) not found
>
> > When I want to list corrupted directory, I get this:
>
> What I get is:
>
> root@wiibroe:/var/spool/squid# find /var/spool/squid/ -type f | xargs ls
> > /dev/null
> find: /var/spool/squid/01/C5/0001C5DA: Ingen sådan fil eller filkatalog
> find: /var/spool/squid/01/C5/0001C5E6: Ingen sådan fil eller filkatalog
> find: /var/spool/squid/03/F5/0003F5E9: Adgang nægtet
> find: /var/spool/squid/04/B6/0004B6E0: Adgang nægtet
>
> (Ingen sådan fil eller filkatalog = No such file or directory
> Adgang nægtet = Access denied)
>
> Rasmus Bøg Hansen
>
> --
> -- [ Rasmus 'Møffe' Bøg Hansen ] --
> if (getenv(EDITOR) == "vim") {karma++};
> - [ moffe at amagerkollegiet dot dk ] -
-
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/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
This is why our next patch will detect the use of gcc 2.96, and complain, in the reiserfs Makefile. Hans Jan Kasprzak wrote: > > Hello, > > with ReiserFS support in 2.4.1 I have decided to give it a try. > I created a filesystem on a spare partition, mounted it as /mnt, > and tried to use it. The kernel crashed - I am able to reproduce it > with the following steps: > > - boot linux with init=/bin/bash > - [optional] /sbin/mkreiserfs /dev/hdd1 (it can be reproduced even > on freshly created FS) > - mount -t reiserfs /dev/hdd1 /mnt > - cp -arv /usr /mnt > > I am attaching the details, feel free to ask for more information, > if you want it. Please Cc: me in any reply. > > Oops is a NULL pointer dereference at address 0010, > EIP is c017c7c3 (in check_leaf), EFLAGS is 00010292, Process is "cp", > Code: 8b 52 10 ff d2 59 5b 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02, > Call trace is the following: > c015f459 (in do_balance) > c0179466 (in fix_nodes) > c0179476 (also in fix_nodes) > c018612c (in reiserfs_insert_item) > c0173cb4 (near the end of reiserfs_new_symlink) > c0174170 (in reiserfs_new_inode) > c0170cbd (in reiserfs_symlink) > c0142a45 (in d_alloc) > c013c825 (in vfs_symlink) > c013c8de (in sys_symlink) > c0109023 (in system_call) > > All numbers are written by hand from the screen, so there may > be a minor mistakes. Looking at the cp output, it seems it crashed > while copying the symlink "/usr/bin/sgml2xml -> osx" to /mnt/bin. > > My computer is almost generic Red Hat 7.0 with all updates. > Hardware is K6-2 @523 MHz, 128M RAM, VIA VT82C598 north bridge. > > I tried to create ext2 filesystem on /dev/hdd1, and then > cp -arv /usr /mnt worked fine. > > The kernel config (grep '=[ym]' /usr/src/linux/.config) is the > following (no modules were loadaed, though): > > CONFIG_X86=y > CONFIG_ISA=y > CONFIG_UID16=y > CONFIG_EXPERIMENTAL=y > CONFIG_MODULES=y > CONFIG_KMOD=y > CONFIG_MK6=y > CONFIG_X86_WP_WORKS_OK=y > CONFIG_X86_INVLPG=y > CONFIG_X86_CMPXCHG=y > CONFIG_X86_BSWAP=y > CONFIG_X86_POPAD_OK=y > CONFIG_X86_ALIGNMENT_16=y > CONFIG_X86_TSC=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_NOHIGHMEM=y > CONFIG_MTRR=y > CONFIG_NET=y > CONFIG_PCI=y > CONFIG_PCI_GOANY=y > CONFIG_PCI_BIOS=y > CONFIG_PCI_DIRECT=y > CONFIG_HOTPLUG=y > CONFIG_PCMCIA=y > CONFIG_CARDBUS=y > CONFIG_SYSVIPC=y > CONFIG_SYSCTL=y > CONFIG_KCORE_ELF=y > CONFIG_BINFMT_AOUT=m > CONFIG_BINFMT_ELF=y > CONFIG_BINFMT_MISC=y > CONFIG_PARPORT=m > CONFIG_PARPORT_PC=m > CONFIG_PARPORT_PC_FIFO=y > CONFIG_PARPORT_PC_SUPERIO=y > CONFIG_PARPORT_1284=y > CONFIG_BLK_DEV_FD=m > CONFIG_BLK_DEV_LOOP=m > CONFIG_PACKET=y > CONFIG_PACKET_MMAP=y > CONFIG_NETLINK=y > CONFIG_RTNETLINK=y > CONFIG_UNIX=y > CONFIG_INET=y > CONFIG_INET_ECN=y > CONFIG_IPV6=m > CONFIG_IPV6_EUI64=y > CONFIG_IDE=y > CONFIG_BLK_DEV_IDE=y > CONFIG_BLK_DEV_IDEDISK=y > CONFIG_IDEDISK_MULTI_MODE=y > CONFIG_BLK_DEV_IDECS=m > CONFIG_BLK_DEV_IDECD=m > CONFIG_BLK_DEV_IDEPCI=y > CONFIG_IDEPCI_SHARE_IRQ=y > CONFIG_BLK_DEV_IDEDMA_PCI=y > CONFIG_IDEDMA_PCI_AUTO=y > CONFIG_BLK_DEV_IDEDMA=y > CONFIG_IDEDMA_PCI_WIP=y > CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y > CONFIG_BLK_DEV_VIA82CXXX=y > CONFIG_IDEDMA_AUTO=y > CONFIG_BLK_DEV_IDE_MODES=y > CONFIG_NETDEVICES=y > CONFIG_NET_ETHERNET=y > CONFIG_NET_VENDOR_3COM=y > CONFIG_VORTEX=y > CONFIG_HAMACHI=m > CONFIG_PPP=m > CONFIG_PPP_ASYNC=m > CONFIG_PPP_DEFLATE=m > CONFIG_PPP_BSDCOMP=m > CONFIG_WAN=y > CONFIG_COSA=m > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_SERIAL=y > CONFIG_UNIX98_PTYS=y > CONFIG_PRINTER=m > CONFIG_MOUSE=y > CONFIG_PSMOUSE=y > CONFIG_NVRAM=m > CONFIG_RTC=m > CONFIG_AGP=y > CONFIG_AGP_VIA=y > CONFIG_DRM=y > CONFIG_DRM_MGA=y > CONFIG_PCMCIA_SERIAL=y > CONFIG_AUTOFS4_FS=y > CONFIG_REISERFS_FS=y > CONFIG_REISERFS_CHECK=y > CONFIG_ISO9660_FS=m > CONFIG_PROC_FS=y > CONFIG_DEVPTS_FS=y > CONFIG_EXT2_FS=y > CONFIG_CODA_FS=m > CONFIG_NFS_FS=y > CONFIG_NFS_V3=y > CONFIG_NFSD=m > CONFIG_NFSD_V3=y > CONFIG_SUNRPC=y > CONFIG_LOCKD=y > CONFIG_LOCKD_V4=y > CONFIG_MSDOS_PARTITION=y > CONFIG_VGA_CONSOLE=y > CONFIG_VIDEO_SELECT=y > CONFIG_SOUND=y > CONFIG_SOUND_ES1371=y > CONFIG_USB=m > CONFIG_USB_DEVICEFS=y > CONFIG_USB_UHCI=m > CONFIG_USB_AUDIO=m > CONFIG_USB_SCANNER=m > > The dmesg output: > > Linux version 2.4.1 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat >Linux 7.0)) #2 Fri Feb 2 11:46:21 CET 2001 > BIOS-provided physical RAM map: > BIOS-e820: 0009fc00 @ (usable) > BIOS-e820: 0400 @ 0009fc00 (usable) > BIOS-e820: 0001 @ 000f (reserved) > BIOS-e820: 0001 @ (reserved) > BIOS-e820: 07ef @ 0010 (usable) > BIOS-e820: d000 @ 07ff3000 (ACPI data) > BIOS-e820: 3000 @ 07ff (ACPI NVS) > On node 0 totalpages: 32752 > z
Re: ReiserFS Oops (2.4.1, deterministic, symlink
Chris Mason wrote: > Hans, decisions about proper compilers should not be made in each > individual part of the kernel. If unpatched gcc 2.96 is getting reiserfs broke is broke. If you use reiserfs, DO NOT use 2.96. Period. Nobody gains by letting a single user make this mistake. > wrong, it is compiling other parts of the kernel wrong as well. l-k has > discussed this at length already ;-) So, did Linus say no? If not, let's ask him with a patch. Quite simply, neither we nor the users should be burdened with this, and the patch removes the burden. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > So, did Linus say no? If not, let's ask him with a patch. Quite simply, > > neither we nor the users should be burdened with this, and the patch removes > > the burden. > > Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget > to stop those being used as well. Oh look you'll need CVS gcc to build the > kernel... ah but wait that misbuilds DAC960.c... > > Oh look nothing compiles the kernel. > > Congratulations 8) > > Alan Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use reiserfs. It is that simple. How can you even consider defending allowing the use of it without requiring a positive affirmation by the user that they don't know what they are doing and want to do it anyway?:-) I could understand arguing that you don't want to be bothered with protecting the users because you don't have the time, but if somebody else finds the time to write the patch I would indeed encourage Linus to accept patches to test for known bad compilers at make time. It is less work for us all to prevent users from having bugs than to respond to their having them. I look forward to gcc 3.00, and I encourage the compiler guys to get over being (understandably) irked that somebody else released their code prematurely, and to increment the version number to 2.97 so that users can more easily avoid the baddie. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use > > reiserfs. It is that simple. How can you even consider defending allowing the > > use of it without requiring a positive affirmation by the user that they don't > > know what they are doing and want to do it anyway?:-) I could understand > > The kernel documentation explicitly says to use egcs-1.1.2 or 2.95 for x86. > If you want to put in #ifdefs then let me assure you that you will then get > a million emails that 'reiserfs doesnt build'. I went this way with older > gcc's in 2.0 and the amount of mail more than doubled by doing the check I'd rather have them complain it doesn't build than never complain because they think reiserfs is still a little too new and has bugs. Also, I just don't think my convenience matters as much as that of the users. I don't want to use #ifdefs, I want it to die explosively and verbosely informatively. make isn't the most natural language for that, but I am sure Yura can find a way. > > If people use other compilers then certainly ignore the bug reports. For 2.2 > until recently that was policy with gcc 2.95 We don't (at least not intentionally, surely someone is going to mention one where we did) ignore bug reports on our mailing list. Period. We are capable of telling users, you know, this is user error, if you want detailed help send me a note that you have put $25 in the mail, and I'll have someone give you step by step help with it. If it is easy to narrow the user error down from the first email I typically just tell them what it is. > > Also remember to check for 2.96 but not 2.96-69 (the errata one) and remember > to do specific architecture tests as there is no other compiler set available > for IA64 for example. > > > to respond to their having them. I look forward to gcc 3.00, and I encourage > > the compiler guys to get over being (understandably) irked that somebody else > > Gcc 3.0 CVS branch wont build the kernel either right now - DAC960 fails. > > Alan Please delay shipping the 3.0 CVS branch on RedHat for a while.:-) Sorry, I couldn't resist. Look, everybody lets a piece of software slip out that should not have gone at some point in their career. It is just that RedHat is big enough that everyone is inconvenienced when they do so, and so we need to patch a Makefile to reduce the annoyance. No biggie. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
Alan Cox wrote: > > > As it stands, there is no way to determine programatically whether > > gcc-2.96 is broken or now. The only way to do it is to check the RPM > > version -- which, needless to say, is a bit difficult to do from the > > C code about to be compiled. So I can't really blame Hans if he decides > > to outlaw gcc-2.96[.0] for reiserfs compiles. > > Oh I can see why Hans wants to cut down his bug reporting load. I can also > say from experience it wont work. If you put #error in then everyone will > mail him and complain it doesnt build, if you put #warning in nobody will > read it and if you dont put anything in you get the odd bug report anyway. > > Basically you can't win and unfortunately a shrink wrap forcing the user > to read the README file for the kernel violates the GPL .. > > Jaded, me ? > > Alan I fear that you are speaking from experience about the complaints it doesn't build, and that there is a strong element of truth in what you say. That said, my opinion is that bug reporting load is not as important as bug avoidance, but I understand your position has merit to it also. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > my convenience matters as much as that of the users. I don't want to use > > #ifdefs, I want it to die explosively and verbosely informatively. make isn't > > the most natural language for that, but I am sure Yura can find a way. > > Run a small shell check and let it fail if the shell stuff errors. > > The fragment you want is > > if [ -e /bin/rpm ]; then > X=`rpm -q gcc` > if [ "$X" = "gcc-2.96-54" ]; then > echo "*** GCC 2.96-54 will miscompile Reiserfs. Please update your >compiler" > echo "See http://www.redhat.com/support/errata/RHBA-2000-132.html" > exit 255 > fi > fi > > > Please delay shipping the 3.0 CVS branch on RedHat for a while.:-) Sorry, I > > couldn't resist. > > Grin. gcc 3.0 is going to be just as much fun Im sure, but finally should give > everyone a stable C and more importantly C++ base including the LSB standards. > > Alan Ok, thanks Alan, we'll use it, Yura, write something resembling or equal to this, test it, and check it into our CVS branch. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > It makes sense to refuse to build a piece of the kernel if it break's > > a machine - anything else is a timebomb waiting to explode. > > The logical conclusion of that is to replace the entire kernel tree with > > #error "compiler or program might have a bug. Aborting" No, this is a compiler that DOES have a bug. ReiserFS is, as best as I can make it, for mission critical servers where some sysadmin doesn't want to explain it to the CEO. There are plenty of ways that I fail at this, but not intentionally. These sorts of mission critical servers are frequently installed by persons short on sleep because a whole lot of things more interesting than ReiserFS had to be gotten working for that server, and who are barely able to convince their boss that compiling a kernel themselves is an okay thing for them to be allowed to do. Taking an attitude of, you didn't read the README, you didn't read Slashdot, you just assumed the distro wouldn't install a compiler unable to compile the kernel, you lose, is not the way I treat such customers. Our users have better things to do than read our FAQ. They REALLY do. ReiserFS is a product of only marginal interest to them. They trust that it will just work because it isn't a Microsoft product. My design objective in ReiserFS is not to say that it wasn't my fault they had that bug because they are so ignorant about a filesystem that really isn't very important to them unless it screws up. My design objective is to ensure they don't have that bug. They are more important than me. > > The kernel is NOT some US home appliance festooned with 'do not eat this > furniture' and 'do not expose your laserwrite to naked flame' messages. > The readme says its been tested with egcs-1.1.2 and gcc 2.95. > > The same people who can't read documentation will just mail the list with > 'it doesnt compile, help' or 'it doesnt compile, you suck' in less enlightened > cases/ > > Large numbers of people routinely build the kernel with 'unsupported' compilers > notably the pgcc project people and another group you will cause problems for > - the GCC maintainers. They use the kernel tree as part of the test set for > their kernel, something putting #ifdefs all over it will mean they have to > mess around to fix too. > > Alan A moment of precision here. We won't test to see if the right compiler is used, we will just test for the wrong one. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > > their kernel, something putting #ifdefs all over it will mean they have to > > > mess around to fix too. > > > > > A moment of precision here. We won't test to see if the right compiler is used, > > we will just test for the wrong one. > > Ok that makes a lot more sense Ok, so with that last clarification, we are all in agreement I think. Thanks for the code frag Alan, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
I would agree with you, and I was about to write something saying that trusting that rpm is installed is bad, except that then I realized, only RedHat made this error, and only RedHat installs need this protection. Now, if we want to have a more general bad gcc's list, and we envision this code evolving, then yes, Alan's code is way too specific, and we should do it differently so as to force them to increment what gcc -v returns whenever they want anybody to pay attention to their having fixed a bug. I was trying to be sociable for once though Hans "J . A . Magallon" wrote: > > On 02.02 Hans Reiser wrote: > > Alan Cox wrote: > > > Run a small shell check and let it fail if the shell stuff errors. > > > > > > The fragment you want is > > > > > > if [ -e /bin/rpm ]; then > > > X=`rpm -q gcc` > > > if [ "$X" = "gcc-2.96-54" ]; then > > > echo "*** GCC 2.96-54 will miscompile Reiserfs. Please > > update your compiler" > > > echo "See >http://www.redhat.com/support/errata/RHBA-2000-132.html" > > > exit 255 > > > fi > > > fi > > Ok, thanks Alan, we'll use it, Yura, write something resembling or equal to > > this, test it, and check it into our CVS branch. > > > > Please, do not do so. That depends on the PACKAGE name and version, and there > is no standard way of versioning a patched gcc. > The -54 is a RH'ism, for example Mandrake Cooker includes patches from > different sources, and gcc is versioned like > > werewolf:~# rpm -q gcc > gcc-2.96-0.33mdk > > and ChangeLog is: > > werewolf:~# rpm -q --changelog gcc > * Mon Jan 15 2001 David BAUDENS <[EMAIL PROTECTED]> 2.96-0.33mdk > > - Fix build on PPC > > * Mon Jan 15 2001 Chmouel Boudjnah <[EMAIL PROTECTED]> 2.96-0.32mdk > > - Try to fix when alternatives is broken in %post. > - Merge with RH package (rel70) of Jakub : > ^^^ > .. > > so it suits a 2.96-70 gcc. > > -- > J.A. Magallon $> cd pub > mailto:[EMAIL PROTECTED] $> more beer > > Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
Alan Cox wrote: > > > administrator that has worked in large multi hundred million dollar compani= > > es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent= > > ion IS the right answer. If the gcc people need to compile with the .96 rh = > > version then they can apply a removal patch hans provides in the crash mess= > > age. This makes it easy to remove the safeguard and blow yourself up at wil= > > l after being suitibly called a dumbass. > > With all due respect, if you are running $75,000/hr of lost income (which btw > is small fry to a lot of folks) shouldn't you have an engineering team who > a) read the documentation. > b) run tests before rolling out software > > Alan Think of it as being like gun safety. You don't seek to develop habits that protect you when you are awake and alert and paying attention, you strongly seek to develop the sort of habits that will protect you if for one moment your attention wanders and you do something completely stupid. Oh dear, there may be some cultural translation difficulty with this example.:-) User protection is a variant on that. To have an attitude that if the user was only alert and intelligent at the moment and as educated as you are in how to compile a kernel, this is just, ahem, not right. All things must be kept in balance though, and not taken to extremes. But when the number of users complaining exceeds some amount relative to the cost to protect them, they should be protected from their lack of education in what distro to not trust the compiler on. You can go ahead and write software for the always alert and always intelligent and never too hasty and always read the README users, and I'll be happy with having the rest of the market for ReiserFS.:-) Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
Alan Cox wrote: > > > In an __init function, have some code that will trigger the bug. > > This can be used to disable Reiserfs if the compiler was bad. > > Then the admin gets a printk() and the Reiserfs mount fails. > > Thats actually quite doable. I'll see about dropping the test into -ac that > way. NO!! It should NOT fail at mount time, it should fail at compile time. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
Alan Cox wrote: > > > No. There are *many* other compilers out there which are much *more* broken > > then anything RedHat has recently shipped. Unfortunatly, there is no easy > > way to accuratly test for such bugs (because once they can be boiled down to > > a simple test they are very rapidly fixed, what's left is voodoo). > > The problem isn't so much that compilers get bugs and they get fixed as > soon as a good test case pops up, its that end users don't habitually check > for a compiler update. Being able to say 'look go get a new compiler' is > productive. Especially as the kernel can panic with a URL ;) > > Alan Here we agree. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > > Thats actually quite doable. I'll see about dropping the test into -ac that > > > way. > > NO!! It should NOT fail at mount time, it should fail at compile time. > > I was thinking boot time. and if reiserfs is the root partition? You really want to make them reboot to the old kernel and recompile rather than making them just recompile? Stop trying to blame something other than the compiler, it is ridiculous. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink
Alan Cox wrote: > > > > I was thinking boot time. > > and if reiserfs is the root partition? You really want to make them reboot to > > the old kernel and recompile rather than making them just recompile? > > I want to make sure they get a sane clear message telling them where to > find the correct compiler and that they didnt read the docs > > > Stop trying to blame something other than the compiler, it is ridiculous. > > WTF does it have to dow with blaming something other than the compiler ? > > Its going to print something like > > Linux 2.4.2-ac3 blah blah > Error: This kernel was built with a buggy gcc. Please go to > http:// and upgrade Sorry, thought you were going to make it only reiserfs disabling, ok, if we do both this and make the compile fail, that is pretty thorough, effective, useful, etc. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] mongo.sh 2.2.18: do_try_to_free_pages failed ...
Wenzhuo Zhang wrote: > > Hi, > > I got the VM error "VM: do_try_to_free_pages failed for mongo_read..." > and then I couldn't log into the system, when stress testing > reiserfs+raid0 setup on a 2.2.18 box using the reiserfs benchmark > mongo.sh. The problem was reporduceable on each run of mongo.sh. > > ./mongo.sh reiserfs /dev/md0 /mnt/testfs raid0-rfs 3 > > Thinking the raid code might cause the problem, I tested on reiserfs > only, but I got the same error message. Later, I found the same > problem running mongo.sh on an ext2 partition (stock kernel without > any patches). > > I guess this problem is not reiserfs specific. What can I do now to > solve the problem? > > Here is the hardware configuration of my test box: > PIII 600, 256M, Adaptec AIC-7896 SCSI controller, two Quantum SCSI > disks. > > Regards, > -- > Wenzhuo Honestly, the best thing to do is to upgrade to 2.4.1. VM on 2.2.recent is not in good condition, and reiserfs exacerbates it. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Apparent instability of reiserfs on 2.4.1
I know that our number of users has increased, but I doubt that the increase is sufficient to match the marked increase in bug reports on reiserfs-list. Please be patient as we work on this. We will issue a patch this week that will fix some bugs (NFS i_generation count losing, and space leakage on crash due to preallocated blocks being lost). We will also change the default for mkreiserfs to creating the new 2.4 only format, as this (we have belatedly realized) is probably the cause of many users reporting they can't create large files. We have a bug affecting add_entry which we suspect is due to our rename not being adequately atomic and leaving hidden directory entries in the filesystem, and we are exploring how this might happen (improper journaling, we don't yet know) Treat this description with the usual skepticism attached to any explanation of a bug not fixed yet, our diagnosing continues This is the most worrisome bug for us stability wise. It seems ~ a user a day encounters it. This patch for sure also won't fix the zeros getting added to syslog files bug which we are desperate to learn how to reproduce at our site. Thank you for your patience. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Chris Wedgwood wrote: > > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > I run Reiser on all but /boot, and it seems to enjoy corrupting my > mbox'es randomly. > > what kind of corruption are you seeing? > > This also occurs in some log files, but I put it down to syslogd > crashing or something. > > syslogd crashing shouldn't corrupt files... > > --cw There is a known bug in which nulls get added to log files. We are having trouble reproducing it on our machines. There is an elevator bug in 2.4 which just got found/fixed. We don't know what part of our bug reports are due to it. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Daniel Stone wrote: > > On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: > > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > > > I run Reiser on all but /boot, and it seems to enjoy corrupting my > > mbox'es randomly. > > > > what kind of corruption are you seeing? > > Zeroed bytes. This sounds like the same bug as the syslog bug, please try to help Chris reproduce it. zam, if Chris can't reproduce it by Monday, please give it a try. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
David Ford wrote: > > Alan Cox wrote: > > >> I run Reiser on all but /boot, and it seems to enjoy corrupting my > >> mbox'es randomly. > >> Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640 > >> chipset with the fixes enabled. > >> This also occurs in some log files, but I put it down to syslogd > >> crashing or something. > > > > > > Before you put that down to reiserfs can you chek 2.4.2-pre2. It may be > > problems below the reiserfs layer > > Just as an aside, I've watched this conversation go on and on while I > run reiserfs on several servers, workstations, and a notebook. I have > current kernels and have watched carefully for corruption. I haven't > seen any evidence of corruption on any of them including my notebook > which has a bad battery and bad power connection so it tends to > instantly die. > > Alan, is there a particular trigger to this? > > -d Guys, instability is a relative word. One of our users in Russia said that reiserfs was as stable as a mountain, and he didn't understand my email. We have some number of users, I wish I really knew how many. If you look at a few hundred thousand mountains, you'll discover that a number of them are really quite unstable. We used to get a bug report a week, now we get one or two a day. Does this mean we went from a few hundred thousand mountains to a few million? I don't really know. I can assure the users though that we have an extensive testing procedure, and that our releases all pass a testing that can roughly be described as hammering the filesystem every different way we can think of (this is more limited than what being put into the kernel by Linus does) for twelve or more hours. What I do know is the following: there was a recent elevator bug fix. Our filesystem is a journaling filesystem and it is extremely dependent on an assumption that nothing is going to get written to disk before it should. I think fsck even makes assumptions about certain states relating to rename being made atomic never reaching disk (and I think this is being fixed thanks to this bug). Could this cause the bug in which syslog gets zeros in it? Don't know, we haven't reproduced that bug yet though it "should" be straightforward to reproduce. We do have an NFS bug, which Nikita is still fixing. What I can tell you is that in a few weeks we will have it back to a bug report every week or two, and until we do version 4 of ReiserFS is going to be stalled (not so different from Linux 2.5 being stalled until 2.4 satisfies Linus). Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Alan Cox wrote: > Before you put that down to reiserfs can you chek 2.4.2-pre2. It may be > problems below the reiserfs layer I forgot, this bug exists on reiserfs for Linux 2.2.*, so it isn't going to be fixed by 2.4.2 (assuming that the bug is not in 2.2.*). Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Adrian Phillips wrote: > > Does your test procedure include other systems, for example reiserfs > plus NFS ? Our NFS testing is simply inadequate, we need a copy of LADDIS but haven't found the money for it yet. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Adrian Phillips wrote: > > >>>>> "Hans" == Hans Reiser <[EMAIL PROTECTED]> writes: > > Hans> Adrian Phillips wrote: > >> Does your test procedure include other systems, for example > >> reiserfs plus NFS ? > > Hans> Our NFS testing is simply inadequate, we need a copy of > Hans> LADDIS but haven't found the money for it yet. > > Excuse my ignorance, but what is LADDIS ? > > Sincerely, > > Adrian Phillips > > -- > Your mouse has moved. > Windows NT must be restarted for the change to take effect. > Reboot now? [OK] LADDIS is the industry standard benchmark for NFS. It crashes for ReiserFS and NFS. We can't afford to buy it, as it is proprietary software. Once Nikita has finished testing his changes, we will ask someone to test it for us though. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Alan Cox wrote: > > > LADDIS is the industry standard benchmark for NFS. It crashes for ReiserFS and > > NFS. We can't afford to buy it, as it is proprietary software. Once Nikita has > > finished testing his changes, we will ask someone to test it for us though. > > > > Do you know if the connectathon test suites show the problem? Not the slightest idea. Is the connectathon test suite something that stresses the FS heavily? If so, we can always add it to our stable, whether or not it stresses this particular bug. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink
"Albert D. Cahalan" wrote: > > Hans Reiser writes: > > Alan Cox wrote: > >> [Ablert Cahalan] > > >>> In an __init function, have some code that will trigger the bug. > >>> This can be used to disable Reiserfs if the compiler was bad. > >>> Then the admin gets a printk() and the Reiserfs mount fails. > >> > >> Thats actually quite doable. I'll see about dropping the test > >> into -ac that way. > > > > NO!! It should NOT fail at mount time, it should fail > > at compile time. > > Detection at compile time is not reliable. Just last week, on a > plain x86 box with a good gcc, I was compiling with a compiler > called "/usr/local/bin/powerpc-linux-gcc". Guess what that does. > > My compiler was not in the RPM database. My compiler could not > produce executables that would run on the build system, so build-time > tests wouldn't work. Compiler version information is fairly useless, > since x86-specific bugs don't matter at all. Maybe I even patched > my compiler. > > Complaints about the local compiler are useful, but not sufficient. > They only protect the menuconfig program, the mkdep program... > As above, actual bug tests are better than trying to interpret > what the compiler reports for a version. We only detect bad compilers, and our particular bad compiler only exists on one particular distro, so it works. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Marcelo Tosatti wrote: > > On Sun, 11 Feb 2001, Chris Mason wrote: > > > > > > > On Sunday, February 11, 2001 10:00:11 AM +0300 Hans Reiser > > <[EMAIL PROTECTED]> wrote: > > > > > Daniel Stone wrote: > > >> > > >> On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: > > >> > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > >> > > > >> > I run Reiser on all but /boot, and it seems to enjoy corrupting my > > >> > mbox'es randomly. > > >> > > > >> > what kind of corruption are you seeing? > > >> > > >> Zeroed bytes. > > > > > > This sounds like the same bug as the syslog bug, please try to help Chris > > > reproduce it. > > > > > > zam, if Chris can't reproduce it by Monday, please give it a try. > > > > > > > I had a bunch of scripts running over the weekend to try and reproduce > > this, but the results were ruined when a major storm killed the power (no, > > still haven't gotten around to configuring my UPS to shut things down ;-). > > > > So, I'll try again. > > Chris, > > Do you know if the people reporting the corruption with reiserfs on > 2.4 were using IDE drives with PIO mode and IDE multicount turned on? > > If so, it may be caused by the problem fixed by Russell King on > 2.4.2-pre2. > > Without his fix, I was able to corrupt ext2 while using PIO+multicount > very very easily. Was the bug you describe also present in the 2.2.* series? If not, then the bugs are not the same. Hans - 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://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Marcelo Tosatti wrote: > > On Mon, 12 Feb 2001, Hans Reiser wrote: > > > Marcelo Tosatti wrote: > > > > > > On Sun, 11 Feb 2001, Chris Mason wrote: > > > > > > > > > > > > > > > On Sunday, February 11, 2001 10:00:11 AM +0300 Hans Reiser > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > Daniel Stone wrote: > > > > >> > > > > >> On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: > > > > >> > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > > > >> > > > > > >> > I run Reiser on all but /boot, and it seems to enjoy corrupting my > > > > >> > mbox'es randomly. > > > > >> > > > > > >> > what kind of corruption are you seeing? > > > > >> > > > > >> Zeroed bytes. > > > > > > > > > > This sounds like the same bug as the syslog bug, please try to help Chris > > > > > reproduce it. > > > > > > > > > > zam, if Chris can't reproduce it by Monday, please give it a try. > > > > > > > > > > > > > I had a bunch of scripts running over the weekend to try and reproduce > > > > this, but the results were ruined when a major storm killed the power (no, > > > > still haven't gotten around to configuring my UPS to shut things down ;-). > > > > > > > > So, I'll try again. > > > > > > Chris, > > > > > > Do you know if the people reporting the corruption with reiserfs on > > > 2.4 were using IDE drives with PIO mode and IDE multicount turned on? > > > > > > If so, it may be caused by the problem fixed by Russell King on > > > 2.4.2-pre2. > > > > > > Without his fix, I was able to corrupt ext2 while using PIO+multicount > > > very very easily. > > > > Was the bug you describe also present in the 2.2.* series? If not, then the > > bugs are not the same. > > N. Zam will try to reproduce it tomorrow, he successfully escaped me today and got to write fun code (a simpler block allocator) instead. Hans - 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://vger.kernel.org/lkml/
Re: ReiserFS 2.4.4/3.x.0k-pre2
Samium Gromoff wrote: > > Hello, > I`m still experiencing file tail corruptions > on subj. > And more: after i had restored bblocked patrition > (by relying on drive`s ability to remap bblks on > write by wroting small modification of debugreiserfs > which zeroified all bblks), i had _runtime_ tail >corruptions of the mc`s dir hotlist which i tried >to rewrite again and again. > i found, that "sync"ing after modifying helps to keep > file fine, so it does until now. > - > 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/ we would be very eager to receive any testing method that could incurr tail corruption on a disk drive other than the one that you have that is known unreliable. Hans - 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/
Re: LANANA: To Pending Device Number Registrants
Chris Wedgwood wrote: > > Or you can fall back to mounting by UUID, which is globally > unique and still avoids referencing physical location. You also > don't need to manually set LABELs for UUID to work: all e2fsprogs > over the past couple of years have set UUID on partitions, and > e2fsck will create a new UUID if it sees an old filesystem that > doesn't already have one. > > Other filesystems such as reiserfs at present don't have such a > thing. I brought this a while ago and in theory it's not too hard, we > just need to get Hans to officially designate part of the SB or > whatever for the UUID. > > --cw > - > 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/ work out a patch with monstr, and I am sure he will accept it. Hans - 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/
Re: [reiserfs-list] reiserfs, xfs, ext2, ext3 (simple benchmarks)
Steve Lord, please work with Yura to resolve the bug that mongo triggers in XFS. I assume you will be as eager as we usually are for any script that can reproduce a bug. Yura's benchmarks don't really show off the strengths of XFS, just as the spanish benchmark didn't show off the strengths of reiserfs. I expect that once mongo works there will be areas where XFS has clear advantages, probably in large file IO and for reads. We look forward to measuring reiser4 against XFS during linux 2.6, though I suspect there will always be (changing) areas where the two filesystems each offer the users different advantages. Hans "Yury Yu. Rupasov" wrote: > > "Yury Yu. Rupasov" wrote: > > > > Hans Reiser wrote: > > > > > > Andrey Tulenev wrote: > > > > > > > Hello reiserfs-list, > > > > > > > > http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.1/0358.html > > > > http://bulma.lug.net/body.phtml?nIdNoticia=626 > > > > > > > > -- > > > > Best regards, [Team òõäîÉË] > > > > Andrey mailto:[EMAIL PROTECTED] > > > > Pager: 913-5353 ab.17403 or [EMAIL PROTECTED] > > > > > > I don't understand why you all didn't run more serious benchmarks. > > > We'll try mongo.pl from the benchmarks section of www.namesys.com, and > > > report on the results. > > > > > > Hans > > > > Yes, we have some results : ext2 vs. reiserfs on our web page : > > http://www.namesys.com/benchmarks/benchmark-results.html > > > > But yes, now when xfs is released, it would be not bad to check > > it performance too. The results will be ready a bit later. > > > > I have some results now : bonnie++ for ext2, reiserfs and xfs : > > ftp://ftp.botik.ru/rented/namesys/ftp/pub/linux+reiserfs/gif/a.html > > Linux-2.4.2+xfs-1.0-patches, > > There was no problems to apply the next xfs patches > to pure linux-2.4.2 : > > linux-2.4-xfs-1.0.patch > linux-2.4.2-core-xfs-1.0,patch > > Test Machine : Celeron 500, 128 MB RAM, >8 GB test partition of 36 GB IDE HDD. > > The bonnie++ results show that reiserfs is much more faster > in case of big amount of files (3 files here). > > Here are also dbench results : > > ext2 xfs reiserfs > - > dbench 1 15.606219.073223.1156mb/sec > dbench 58.449011.678111.8350mb/sec > dbench 109.3481 6.1847 8.9247mb/sec > dbench 207.3631 2.6893 6.9256mb/sec > > Unfortunately, I have no mongo.pl results, because the system > hangs during performing mongo test on xfs system. > > I had to press "reset" button to reboot system, because all > others ways did not work. > > There was no any error messages in the system log. > > Thanks, > Yura. - 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/
Re: New XFS, ReiserFS and Ext2 benchmarks
Ricardo Galli wrote: > > Hi, > you can find at http://bulma.lug.net/static/ a few new benchmarks among > Reiser, XFS and Ext2 (also one with JFS). > > This time there is a comprehensive Hans' Mongo benchmarks > (http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and > read/write/fsync operations tests (I was very careful of populating the > cache before the measures for the last two cases). > > Regards, > > --ricardo > http://m3d.uib.es/~gallir/ These are interesting benchmarks, my only caveats are that make bzImage is probably CPU bound not IO bound (the traditional value of compiles as FS benchmarks does not apply to Linux filesystems, as they don't do the misdesigned synchronization policy of older Unices, and compiles are CPU bound for them in my experience), that I don't understand fully why we are so much faster at the cp -ar, and I would like Yura to try to reproduce the cp -ar as it seems too good to be true. Thanks for investing the time into this Ricardo. Hans - 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/
Re: [reiserfs-dev] Re: New XFS, ReiserFS and Ext2 benchmarks
My apologies, I meant that the make is probably compiler bound (I said CPU bound) not FS bound. We find that one must use cp and similar utilities (not compilers) to become FS bound when using a Linux FS (unlike the older Unixes for which compiles were considered excellent benchmarks). Hans Reiser wrote: Hans > > Ricardo Galli wrote: > > > > Hi, > > you can find at http://bulma.lug.net/static/ a few new benchmarks among > > Reiser, XFS and Ext2 (also one with JFS). > > > > This time there is a comprehensive Hans' Mongo benchmarks > > (http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and > > read/write/fsync operations tests (I was very careful of populating the > > cache before the measures for the last two cases). > > > > Regards, > > > > --ricardo > > http://m3d.uib.es/~gallir/ > > These are interesting benchmarks, my only caveats are that make bzImage is > probably CPU bound not IO bound (the traditional value of compiles as FS > benchmarks does not apply to Linux filesystems, as they don't do the misdesigned > synchronization policy of older Unices, and compiles are CPU bound for them in > my experience), that I don't understand fully why we are so much faster at the > cp -ar, and I would like Yura to try to reproduce the cp -ar as it seems too > good to be true. > > Thanks for investing the time into this Ricardo. > > Hans - 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/
Re: [reiserfs-dev] Re: New XFS, ReiserFS and Ext2 benchmarks
Ricardo Galli wrote: > I was equally suprised, not only due to the wall-clock time but also to the > CPU. So, I think the cache is the major player when compiling a kernel that > was _just_ copied from another file system (still in buffer/cache). You might consider rebooting to flush the cache. Hans - 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/
Re: Dying disk and filesystem choice.
monkeyiq wrote: > > Hi, > Could I please be CC'd replies. > > To keep it short and sweet, I have a 45Gb IBM drive that > is slowly dying by getting more bad sectors. I have already > returned my first one to get the current disk, so would like > to use the current one for a while before returning it for > another disk that will prolly just start dying again. > > I am using reiserfs at the moment, which doesn't really like > to work on a dying drive. for example, doing a make fails to > work even though it is *creating* files on the disk, it fails > to do so because it hits new bad sectors and doesn't seem to > remap them. > > I am wondering what advise on filesystem choice the list as > and any other options I can use to get the kernel to remap > bad blocks. > > Thanks. > > -- > --- > It's the question, http://witme.sourceforge.net > If you think education is expensive, try ignorance. > -- Derek Bok, president of Harvard > > - > 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/ You can get the badblocks patch from Nikita and continue using reiserfs if you want. ext2 will also work. We haven't sent the badblocks patch to Linus solely because it is a feature not a bugfix, and code-freeze is on. Hans - 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/
Re: Dying disk and filesystem choice.
Andi Kleen wrote: > > On Thu, May 24, 2001 at 12:58:14AM -0600, Andreas Dilger wrote: > > Well reiserfs is probably a very bad choice at this point. It > > does not have any bad blocks support (yet), so as soon as you have > > a bad block you are stuck. > > reiserfs doesn't, but the HD usually has transparently in its firmware. > So it hits a bad block; you see an IO error and the next time you hit > the block the firmware has mapped in a fresh one from its internal > reserves. > > -Andi > - > 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/ No, reiserfs does have badblock support You just have to get it as a separate patch from us because it was written after code freeze. Hans - 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/
Re: Dying disk and filesystem choice.
J Sloan wrote: > > Excellent! > > Will this be in resierfs 4.0 then? > > cu > > jjs > > Hans Reiser schrieb: > > > No, reiserfs does have badblock support > > > > You just have to get it as a separate patch from us because it was written after > > code freeze. No, version 4 won't ship until september 2002, these features are all v3.7, which will be sent to Linus as soon as 2.5.1 opens up. Hans - 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/
Re: Dying disk and filesystem choice.
Erik Mouw wrote: > > On Thu, May 24, 2001 at 09:53:45AM -0700, Hans Reiser wrote: > > No, reiserfs does have badblock support > > > > You just have to get it as a separate patch from us because it was > > written after code freeze. > > IMHO we are not that deep into code freeze anymore. Freevxfs got added > in linux-2.4.5-pre*, so I think that a patch that adds a useful feature > like badblock support would be OK. > > Erik > > -- > J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department > of Electrical Engineering, Faculty of Information Technology and Systems, > Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands > Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] > WWW: http://www-ict.its.tudelft.nl/~erik/ > - > 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/ vxfs is probably a completely separate fs that won't destabilize other filesystems, or at least I hope so. ReiserFS is stable code now, we aren't going to change that by adding features unless they go into the ac series for six weeks or so first. ReiserFS is the SuSE recommended FS, and we can't go destabilizing it. I am told by sistina.com (maintainers of LVM) that in their surveys of the users of LVM, 90% use ReiserFS, and the users of LVM tend very much to be persons with mission critical servers. We sent Linus a patch to mark us as stable not experimental. When we say stable, it means something. Right now it means zero (yes, zero) new bug reports that are not user error or old versions or fsck, since 2.4.4 came out. fsck is improving dramatically in stability every week. I used it myself last week, and got my data back minus the root directory after trashing the front of my partition accidentally. (Which gave me a chance to review its end user usability, which is also improving.) We aren't yet ready to pass the zero a random block and see it recover always excepting what was zero'd test, but we will be before long. One of the things we realized recently is that if the user knows what got trashed, and he can tell this to the FS, it can be very useful for bitmap blocks. Sorry, I wander here. Hans - 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/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Daniel Phillips wrote: > > On Tuesday 22 May 2001 22:10, Andreas Dilger wrote: > > Peter Braam writes: > > > File system journal recovery can corrupt a snapshot, because it > > > copies data that needs to be preserved in a snapshot. During > > > journal replay such data may be copied again, but the source can > > > have new data already. > > > > The way it is implemented in reiserfs is to wait for existing > > transactions to complete, entirely flush the journal and block all > > new transactions from starting. Stephen implemented a journal flush > > API to do this for ext3, but the hooks to call it from LVM are not in > > place yet. This way the journal is totally empty at the time the > > snapshot is done, so the read-only copy does not need to do journal > > recovery, so no problems can arise. > > I suppose I'm just reiterating the obvious, but we should eventually > have a generic filesystem transaction API at the VFS level, once we > have enough data points to know what the One True API should be. > > -- > Daniel > - > 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/ Daniel, implementing transactions is not a trivial thing as you probably know. It requires that you resolve such issues as, what happens if the user forgets to close the transaction, issues of lock/transaction duration, of transaction batching, of levels of isolation, of concurrent transactions modifying global fs metadata and some but not all of those concurrent transactions receiving a rollback, and of permissions relating to keeping transactions open. I would encourage you to participate in the reiser4 design discussion we will be having over the next 6 months, and give us your opinions. Josh will be leading that design effort for the ReiserFS team. Hans - 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/
Re: NULL characters in file on ReiserFS again.
Andrej Borsenkow wrote: > > This happened to me yesterday on kernel-2.4.4-6mdk (Mandrake cooker, based > on 2.4.4-ac14), single reiser root filesystem, mounted with default options. > Hardware - ASUS CUSL2 (i815e chipset), Fujitsu UDMA-4 drive. > > I tried to change hostname and did not have the corresponding entry in > /etc/hosts (or anywhere). As a tesult, startx hung starting X server; it was > not possible to switch to alpha console or kill X server. I pressed reset > and after reboot looked into /var/log/XFree86*log - and there were a bunch > of ^@ there. > > I then run fsck from another system (installed on another partition) but > there was no errors (well, new errors - there was off-by-one free blocks > bitmap mismatch but it was always there, I do not know how to correct it). I > tried the above once more but this time XFree log was O.K. > > So, I really do not know how to reproduce it, but I wanted to give a warning > that a problem still exists (albeit in emergency situation). As Reiser does > not do any fsck after crash, the problem is serious enough IMHO. > > -andrej > > - > 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/ this is the nature of metadata journaling filesystems. - 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/
Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
known VFS bug, ask viro for details, 2.4.5 is not stable because of it, use
2.4.4
Hans
[EMAIL PROTECTED] wrote:
>
> On Thu, May 31, 2001 at 05:04:50PM -0500, Jordan wrote:
> > Alan Cox wrote:
> > >
> > > > I'm staying on 2.4.5-ac5 for whatever it's worth (putting my life on the
> > > > line for the community? kidding...) and will report anything new. I will
> > > > be on the lookout for later ac patches, 2.4.6 ... and hopefully anything
> > > > anybody can share with me about this. I hope we'll see an end to these
> > >
> > > Can you tell me if 2.4.5-ac4 is ok. ac5 has a small 'obviously correct'
> > > reiserfs module unload change that seems the first suspect
> > >
> > > 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/
> >
> > I have seen this same problem with unmounting in 2.4.5-ac5, it was
> > perfectly fine in 2.4.5-ac3 and ac4. I would guess the module unload is
> > what did it.
> >
> 2.4.5-ac4 was fine, 2.4.5-ac5:
>
> /space in /etc/fstab:
>
> /dev/hda10 /space1 reiserfsdefaults 1 2
>
> strace umount /space1:
>
> open("/usr/lib/locale/en_US/LC_TIME", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=2441, ...}) = 0
> old_mmap(NULL, 2441, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001f000
> close(3)= 0
> open("/usr/lib/locale/en_US/LC_NUMERIC", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
> old_mmap(NULL, 44, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002
> close(3)= 0
> open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=104804, ...}) = 0
> old_mmap(NULL, 104804, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40137000
> close(3)= 0
> SYS_199(0x40131ad8, 0, 0x40132760, 0x40130210, 0) = 0
> semop(1074993880, 0x40130210, 0)= 0
> brk(0x8056000) = 0x8056000
> readlink("/space1", 0xbfffe51c, 4095) = -1 EINVAL (Invalid argument)
> open("/etc/mtab", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=680, ...}) = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>0x40021000
> read(3, "/dev/hde1 / ext2 rw 0 0\nproc /pr"..., 4096) = 680
> read(3, "", 4096) = 0
> close(3)= 0
> munmap(0x40021000, 4096)= 0
> oldumount("/space1"
>
> and there it hangs. The kernel doesn't hang, but while 'mount' displays
> /space1 as mounted, ls /space1/ says nothing. df -m reveals:
>
> Filesystem 1M-blocks Used Available Use% Mounted on
> /dev/hda102015 907 1005 48% /space1
>
> Good luck,
> Jurriaan
> --
> The music in my heart I bore long after it was heard no more.
> William Wordsworth
> GNU/Linux 2.4.5-ac5 SMP/ReiserFS 2x1402 bogomips load av: 5.60 2.71 1.16
> -
> 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/
-
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/
Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5
Alexander Viro wrote: > > On Fri, 1 Jun 2001, Hans Reiser wrote: > > > known VFS bug, ask viro for details, 2.4.5 is not stable because of it, use > > 2.4.4 > > Different issue. Missing lock_kernel()/unlock_kernel() in kill_super() > appeared in -pre6 and was fixed in -ac2 or so. -ac5 apparently had > introduced something new, that had been reverted (fixing the problem) > in -ac6. thanks for clarification. Hans - 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/
Re: [RFC] yet another knfsd-reiserfs patch
Why are people afraid to put Neil Brown's code into 2.4? It works, we have tons
of users using it, it is the only nfs solution that has a tested reiserfs user
base, don't worry that it isn't tested and shouldn't go into 2.4 because it is
better tested than any of these quick fixes that are floated by people afraid of
Neil's code am I missing something?
Hans
Chris Mason wrote:
>
> > On Monday, April 23, 2001 10:45:14 AM -0400 Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> Hi guys,
> >>
> >> This patch is not meant to replace Neil Brown's knfsd ops stuff, the
> >> goal was to whip up something that had a chance of getting into 2.4.x,
> >> and that might be usable by the AFS guys too. Neil's patch tries to
> >> address a bunch of things that I didn't, and looks better for the
> >> long run.
> >>
> >
>
> Updated to 2.4.5, with the nfs list cc'd this time in hopes of comments
> or flames...
>
> -chris
>
> diff -Nru a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> --- a/fs/nfsd/nfsfh.c Fri Jun 1 16:08:41 2001
> +++ b/fs/nfsd/nfsfh.c Fri Jun 1 16:08:41 2001
> @@ -116,40 +116,12 @@
> return error;
> }
>
> -/* this should be provided by each filesystem in an nfsd_operations interface as
> - * iget isn't really the right interface
> - */
> -static struct dentry *nfsd_iget(struct super_block *sb, unsigned long ino, __u32
>generation)
> +static struct dentry *dentry_from_inode(struct inode *inode)
> {
> -
> - /* iget isn't really right if the inode is currently unallocated!!
> -* This should really all be done inside each filesystem
> -*
> -* ext2fs' read_inode has been strengthed to return a bad_inode if the inode
> -* had been deleted.
> -*
> -* Currently we don't know the generation for parent directory, so a
>generation
> -* of 0 means "accept any"
> -*/
> - struct inode *inode;
> struct list_head *lp;
> struct dentry *result;
> - inode = iget(sb, ino);
> - if (is_bad_inode(inode)
> - || (generation && inode->i_generation != generation)
> - ) {
> - /* we didn't find the right inode.. */
> - dprintk("fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n",
> - inode->i_ino,
> - inode->i_nlink, atomic_read(&inode->i_count),
> - inode->i_generation,
> - generation);
> -
> - iput(inode);
> - return ERR_PTR(-ESTALE);
> - }
> - /* now to find a dentry.
> -* If possible, get a well-connected one
> + /*
> +* If possible, get a well-connected dentry
> */
> spin_lock(&dcache_lock);
> for (lp = inode->i_dentry.next; lp != &inode->i_dentry ; lp=lp->next) {
> @@ -173,6 +145,92 @@
> return result;
> }
>
> +static struct inode *__inode_from_fh(struct super_block *sb, int ino,
> +int generation)
> +{
> + struct inode *inode ;
> +
> + inode = iget(sb, ino);
> + if (is_bad_inode(inode)
> + || (generation && inode->i_generation != generation)
> + ) {
> + /* we didn't find the right inode.. */
> + dprintk("fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n",
> + inode->i_ino,
> + inode->i_nlink, atomic_read(&inode->i_count),
> + inode->i_generation,
> + generation);
> +
> + iput(inode);
> + return ERR_PTR(-ESTALE);
> + }
> + return inode ;
> +}
> +
> +static struct inode *inode_from_fh(struct super_block *sb,
> + __u32 *datap,
> + int len)
> +{
> + if (sb->s_op->inode_from_fh)
> + return sb->s_op->inode_from_fh(sb, datap, len) ;
> + return __inode_from_fh(sb, datap[0], datap[1]) ;
> +}
> +
> +static struct inode *parent_from_fh(struct super_block *sb,
> + __u32 *datap,
> + int len)
> +{
> + if (sb->s_op->parent_from_fh)
> + return sb->s_op->parent_from_fh(sb, datap, len) ;
> +
> + if (len >= 3)
> + return __inode_from_fh(sb, datap[2], 0) ;
> + return ERR_PTR(-ESTALE);
> +}
> +
> +/*
> + * two iget funcs, one for inode, and one for parent directory
> + *
> + * this should be provided by each filesystem in an nfsd_operations interface as
> + * iget isn't really the right interface
> + *
> + * If the filesystem doesn't provide funcs to get inodes from datap,
> + * it must be: inum, generation, dir inum. Length of 2 means the
> + * dir inum isn't there.
> + *
> + * iget isn't really right if the inode is currently unallocated!!
> + * This should really all be done inside each files
Re: Oops while unmounting a reiserfs partition
get patch from www.namesys.com, bug was added and fixed by viro, we just put the patch up while waiting for 2.4.6 to come out. Hans Mathieu Chouquet-Stringer wrote: > > Hello! > > I just mkreiserfsed a new partition (a 50g hardware raid0 array, I know > this is just a testing machine), mounted it, and then unmounted it, and > OOPS! My kernel version is plain 2.4.5... > If you need more information, let me know. > > Jun 4 17:25:03 nynetops03 kernel: reiserfs: checking transaction log (device 08:11) >... > Jun 4 17:25:07 nynetops03 kernel: Using r5 hash to sort names > Jun 4 17:25:07 nynetops03 kernel: ReiserFS version 3.6.25 > Jun 4 17:26:11 nynetops03 kernel: journal_begin called without kernel lock held > Jun 4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423! > Jun 4 17:26:11 nynetops03 kernel: invalid operand: > Jun 4 17:26:11 nynetops03 kernel: CPU:1 > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64] > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[] > Jun 4 17:26:11 nynetops03 kernel: EFLAGS: 00010282 > Jun 4 17:26:11 nynetops03 kernel: eax: 001d ebx: d8e15f24 ecx: 0001 >edx: 0001 > Jun 4 17:26:11 nynetops03 kernel: esi: df9c5400 edi: ebp: 3b1bfcf3 >esp: d8e15eac > Jun 4 17:26:11 nynetops03 kernel: ds: 0018 es: 0018 ss: 0018 > Jun 4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000) > Jun 4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf >c0268a61 d7e75250 00e8 > Jun 4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60 >0018 d8e15f24 df9c5400 c02a8620 > Jun 4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 >000a c017ffdc d8e15f24 > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] >[journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] >[kill_super+162/288] [path_release+41/48] > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [] [] >[] [] [] [] [] > Jun 4 17:26:11 nynetops03 kernel:[sys_umount+301/352] [sys_munmap+51/80] >[sys_oldumount+12/16] [system_call+51/56] > Jun 4 17:26:11 nynetops03 kernel:[] [] [] >[] > Jun 4 17:26:11 nynetops03 kernel: > Jun 4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 >00 00 00 8d bc 27 > > And the decoded output: > ksymoops 2.4.0 on i686 2.4.5. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.5/ (default) > -m /boot/System.map-2.4.5 (default) > > Warning: You did not tell me where to find symbol information. I will > assume that the log matches the kernel and modules that are running > right now and I'll use the default options above for symbol resolution. > If the current kernel and/or modules do not match the log, you can get > more accurate output by telling me the kernel version and where to find > map, modules, ksyms etc. ksymoops -h explains the options. > > Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not >found in System.map. Ignoring ksyms_base entry > Warning (compare_maps): ksyms_base symbol >machine_real_restart_R__ver_machine_real_restart not found in System.map. Ignoring >ksyms_base entry > Jun 4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423! > Jun 4 17:26:11 nynetops03 kernel: invalid operand: > Jun 4 17:26:11 nynetops03 kernel: CPU:1 > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64] > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > Jun 4 17:26:11 nynetops03 kernel: EFLAGS: 00010282 > Jun 4 17:26:11 nynetops03 kernel: eax: 001d ebx: d8e15f24 ecx: 0001 >edx: 0001 > Jun 4 17:26:11 nynetops03 kernel: esi: df9c5400 edi: ebp: 3b1bfcf3 >esp: d8e15eac > Jun 4 17:26:11 nynetops03 kernel: ds: 0018 es: 0018 ss: 0018 > Jun 4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000) > Jun 4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf >c0268a61 d7e75250 00e8 > Jun 4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60 >0018 d8e15f24 df9c5400 c02a8620 > Jun 4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 >000a c017ffdc d8e15f24 > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] >[journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] >[kill_super+162/288] [path_release+41/48] > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [] [] >[] [] [] [] [] > Jun 4 17:26:11 nynetops03 kernel:[] [] [] >[] > Jun 4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 >00 00 00 8d bc 27 > > >>EIP; c018bb98<= > Trace; c018e2cf > Trace;
Re: [reiserfs-list] Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Daniel Phillips wrote: > Graciously accepted. Coming up with something sensible in a mere 6 > months would be a minor miracle. ;-) > > - what happens if the user forgets to close the transaction? then the user has branched into his own version, or at least that would be my take on it. Another possible method is to expire transactions by persons who lack permission to keep them open indefinitely. I suppose one could expire them to abort, or expire them to commit, both being valid under some circumstances. > >I plan to set a checkpoint there (because the transaction got >too big) and log the fact that it's open. > > - issues of lock/transaction duration > >Once again relying on checkpoints, when the transaction gets >uncomfortably big for cache, set a checkpoint. I haven't thought >about locks > > - transaction batching > >1) Explicit transaction batch close 2) Cache gets past a certain >fullness. In both cases, no new transactions are allowed to start >and as soon as all current ones are closed we close the batch.re6; > > - of levels of isolation > - concurrent transactions modifying global fs metadata >and some but not all of those concurrent transactions receiving a >rollback > >First I was going to write 'huh?' here, then I realized you're >talking about real database ops, not just filesystem ops. I had >in mind something more modest: transactions are 'mv', 'read/write' >(if the 'atomic read/write' is set), other filesystem operations I've >forgotten, and anything the user puts between open_xact and >close_xact. You are raising the ante a little ;-) > >In my case (Tux2) I could do an efficient rollback to the beginning > of the batch (phase), then I would have had to have kept an >in-memory log of the transactions for selective replay. With a >journal log you can obviously do the same thing, but perhaps more >efficiently if your journal design supports undo/redo. > >The above is a pure flight of fancy, we won't be seeing anything >so fancy as an API across filesystems. It is just a matter of time, and we will. I think that the major release AFTER 2.6 will see it. First we have to get a prototype done in time for 2.6 > > - permissions relating to keeping transactions open. >We can see this one in the light of a simple filesystem >transaction: what happens if we are in the middle of a mv and >someone changes the permissions? Go with the starting or >ending permissions? > > Well, the database side of this is really interesting, but to get > something generic across filesystems, the scope pretty well has to be > limited to journal-type transactions, don't you think? don't know what a journal-type transaction is and how it differs from a database transaction. > > -- > Daniel - 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/
Re: reiser4 vs politics: linux misses out again
Horst von Brand wrote: > > > > >> It's not always >>nescesary to let the demand create the means. Give programmers >>some powerful tools and wait and see what wonderful things start >>to evolve. >> >> > >The sad truth is that if you give a random collection of people powerful >tools they misuse them more often than not, creating a huge mess in the >process. That is why it is so hard to design good tools. > > We are rope makers. Our job is to make good rope. If someone might use it to hang dissidents, that does not mean we should now make the rope too inflexible to form a noose. It is important that we know our place. Our place is to help users express themselves the way they want to. It is not our job to keep them from hanging dissidents. If they hang dissidents, we should not change the way we make rope, we should shoot them. Most of our users don't hang dissidents, to the contrary, they do work of value to society, and need their time saved so that they can do more of it. The users of reiser4 know a lot more than I do, and are much wiser than I am. Because I focus on a narrow little area, I am able to do something useful to help them express their greater wisdom more flexibly. I take pride in that. The belief expressed above that powerful tools will be misused more than well used, and the dislike of power for the users it contains, is why we will never do more than talk past each other. Perhaps we should just agree to disagree. Hans - 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/
Re: reiser4 vs politics: linux misses out again
Jim Crilly wrote: > >I thought r3 was journaled from the beginning; the Namesys site credits >Chris with the addition of a relocated and large journal. And yes, a good >bit of the patches were from him. > Chris and I disagree about QA methodology, but I am deeply in debt to him for his contributions. R3 did not have a journal at first, that was his contribution, and a major part of what made reiserfs useful to real users. Hans - 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/
Re: reiser4 plugins
Stefan Smietanowski wrote: > > I think "..." and ".meta" both serve as a logical delimiter. However > some programs implement their own "..." which would make it clash with > them. Naturally if some program created a directory called .meta we're > equally screwed. I chose '' (four dots) because it clashes with less, not three dots. - 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/
Re: reiser4 plugins
Horst von Brand wrote: >Hans Reiser <[EMAIL PROTECTED]> wrote: > > >>Stefan Smietanowski wrote: >> >> >>>I think "..." and ".meta" both serve as a logical delimiter. However >>>some programs implement their own "..." which would make it clash with >>>them. Naturally if some program created a directory called .meta we're >>>equally screwed. >>> >>> > > > >>I chose '' (four dots) because it clashes with less, not three dots. >> >> > >Is this some kind of "My dots are more than yours" contest?! > >/None/ of them is safe. ".meta", "...", "", ".this.has.five.dots." are >all perfectly legal file (or directory) names, POSIXly. If any one of them >won't do, none will. > > There is a long history of encroaching namespaces by creating new keywords in CS, and it is a survivable problem. Clearcase (the version control filesystem) is an excellent example. They have special meanings for @ and some other common characters, and you have to learn how to escape those characters if you use them in Clearcase. It works, it makes users happy, in practice it is far less of a problem than one might think. I think there were two or three times I had to remember how to escape things in 2 years of using it. Better to spend one's mind looking for bugs instead of this issue. - 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/
Re: reiser4 plugins
Neil Brown wrote: > > >Maybe it is worth repeating Al Viro's suggestion at this point. I >don't have a reference but the idea was basically that if you open >"/foo" and get filedescriptor N, then > /proc/self/fds/N-meta >is a directory which contains all the meta stuff for "/foo". >Then it is trivial to get the 'meta' stuff given a filedescriptor and >if you have a pathname, you can always get yourself a filedescriptor. > > This sound like it might be cute, but filedescriptors are too heavy weight for stat data accesses in quantity. In general, the whole file handle paradigm is too heavy for lightweight files. Hans - 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/
Re: Linux On-Demand Network Access (LODNA)
Please treat at greater length how your proposal differs from NFS. Hans Vlad C. wrote: >Recent discussion on ReiserFS 4 has focused on the >advantages and disadvantages of VFS at the kernel >level versus the Desktop Environment (DE) level. I >believe network locations should be administered by >the kernel in a proposed framework called Linux >On-Demand Network Access (LODNA), which would achieve >seamless network integration regardless (or even in >the absence) of DEs, thus increasing usability. > >INTRODUCTION: > >When VFS is implemented at the KDE/GNOME level, we >end up with the unfortunate situation where only >applications native to that DE can access its VFS >files. For example, Mozilla and Firefox (which are >GTK-based) can't access network locations set up under >KDE (see >https://bugzilla.mozilla.org/show_bug.cgi?id=298848). >Making an application aware of non-native VFS requires >serious amount of work, not only to use the other DE's >libraries, but also to embed miniature network clients >for every protocol the application supports. > >The same problem appears in OpenOffice: even though it >can use the KDE filepicker, whenever it accesses a >file on an SSH network location, a message pops up >saying "Protocol 'fish' is supported only partially. >Local copy of the file will be created." > >If Mozilla/Firefox and OpenOffice, which are some of >the most popular applications and which have a strong >developer base, haven't yet been able to achieve >cross-VFS compatibility, you can be certain that other >applications are in the same or worse situation. > >These two examples show why VFS at the DE level is a >temporary hack that only hides the need for such >functionality in the kernel. This hassle can be >completely avoided if the kernel provides standard I/O >functions for files in network locations >(ssh/webdav/ftp/smb/...) because opening and saving >network files would then become completely transparent >(i.e. no different from accessing a local file) from >the application's point of view. > >Having this functionality in the kernel would be a >huge usability plus: we would solve all these problems >in one swish, save application developers a lot of >time, and give users the peace of mind to know that >they can seamlessly access their network files no >matter what application they use. > >PROPOSAL: Linux On-Demand Network Access (LODNA) > >Users would be able to mount network locations under >directories they own. For example, to create a network >location on my home computer pointing to my work >computer (via ssh), I would do: >mount -t ssh [EMAIL PROTECTED]:~ >/home/username/net/remote_computer > >>From then on, whenever I change directory to >/home/username/net/remote_computer, I would be able to >see the files in my computer at work as if they were >local - no more need for fancy VPN! > >Similarly, I would also be able to do: >mount -t smbfs [EMAIL PROTECTED]:~ >/home/username/net/remote_computer >mount -t webdav [EMAIL PROTECTED]:~ >/home/username/net/remote_computer >mount -t ftp [EMAIL PROTECTED]:~ >/home/username/net/remote_computer > >Advantages of LODNA: > >1) Network locations would be fixed in the directory >tree, rather than float around in a DE abstraction >like fish:/ . >2) Remote files would be accessible by all >applications, even the shell. >3) LODNA would be independent of Desktop Environments >(although if present, they could provide GUIs for >things that could otherwise be done from the command >line). For example, KDE could use its existing "Add a >Network Folder" wizard to help users mount network >locations. >4) The user could give or deny other local users >access to his remote locations simply by setting the >permissions of the mount point (eg. chmod 700 >/home/username/net/remote_computer). >5) LODNA would help users who want to access files on >their Local Area Network but who don't know the exact >name or IP address of the destination computer. Such >users could use KDE's Konqueror File Manager >(http://www.konqueror.org/) with the Smb4k >(http://smb4k.berlios.de/) plugin to discover all the >samba servers on their LAN. They could then simply >right-click on a server/share and select "Mount", >which would take them to the "Add a Network Folder" >wizard. >6) LODNA would combine the transparency of NFS with >the flexibility of SSH/SMB/WebDav/FTP. >7) LODNA would allow users to build and manage their >own VPN client. > >CONCLUSION: > >Linux On-Demand Network Access (LODNA) is a proposed >kernel-based method for accessing network locations. >It would provide transparent, unified network access >to all applications and pave the way for highly >intuitive GUIs for managing diverse networks. As a >built-in, multi-protocol VPN client, LODNA would >greatly help employees who work from home, and be a >much needed step towards making Linux viable on the >desktop. > >For now, LODNA is only a concept, but the pieces >needed to make it happen already exist - they just >need
Re: realtime-preempt + reiser4?
Lee Revell wrote: >On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote: > > >>Ingo Molnar's realtime-preempt patches used to be based on the -mm >>kernels, but now they appear to be based on the mainline kernels, so >>they don't support reiser4 (at least until reiser4 is merged into >>mainline, which is looking uncertain as I understand it). >> >> > >It's not uncertain, the reiser4 people just have to address the issues >that were raised on LKML before it will be merged, just like everyone >else. > > Maybe tomorrow the changes will compile. they have been written. - 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/
Re: reiser4 plugins
David Masover wrote: > > That's why we're trying to find something that people won't actually > touch, especially since if we design it right, this will be the last > delimiter introduced at the fs/vfs level. Uh, no, there needs to be about a dozen or so more. But not this year. - 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/
Re: Linux On-Demand Network Access (LODNA)
You might look into SFS by David Mazieres, some concepts in it are likely to interest you. Hans Vlad C. wrote: >--- Hans Reiser <[EMAIL PROTECTED]> wrote: > > >>Please treat at greater length how your proposal >>differs from NFS. >> >> > >I think NFS is not flexible enough because: > >1) NFS requires synchronization of passwd files or >NIS/LDAP to authenticate users (which themselves >require root access on both server and client to >install) >2) NFS by definition understands only its own network >protocol. >3) NFS requires root privileges on the client to >mount. I'm not aware of a way to let normal users >mount an NFS partition other than listing it in the >client's fstab and adding the 'users' option... but >then changing fstab still requires root access. >4) Users have to contact their sysadmin every time >they want to mount a different partition, a different >subdirectory of the same partition, or if they want to >change the local mountpoint, all because the partition >and mountpoint are hard-coded in fstab. > >On the other hand, I envision the following: > >1) No authentication layer required other than the >authentication built into the protocol. All the user >needs is the DNS/IP address of the server, a username, >a password, a path on the server, and a local >directory they own to act as a mountpoint. Note that >the user's identity on the server is not tied to his >identity on the client, as it is the case with NFS, >but rather the user can chose which username to >"Connect As" when he performs the mount. >2) Support for multiple network protocols. >3) No need for root privileges when choosing what to >mount and where to mount. Some may say this is a >security risk, but I see it as improved usability. >After all, DE-level implementations like KDE's fish:/ >don't require root privileges either. Nevertheless, I >think there should be some sort of switch where the >sysadmin can allow/deny user mounting on a global or >per user basis (rather than a per fstab-line basis). > >Reasons 3 and 4 for why NFS is not flexible enough >could also apply to the current Linux implementation >of smbfs, which leads me to believe that part of the >problem lies in the fact that users can't mount >locations that aren't explicitly listed in fstab. I >guess a per fstab-line basis of allowing mounts makes >sense when there are a finite number of devices, but >it doesn't make much sense when there are an infinite >number of network addresses. I'm just thinking out >loud here, but would it be possible to specify ranges >of addresses and directories using wildcards? Such a >line in fstab would look like: >*.myhost.com:/home/* /home/* nfs >rsize=8192,wsize=8192,timeo=14,users > >In this case, users could do: >mount -t nfs host1.myhost.com:/home/username >~/remote_home > >but they couldn't do: >mount -t nfs host1.myhost.com:/tmp ~/remote_tmp > >After receiving several suggestions, it appears that >FUSE (http://fuse.sourceforge.net/) and the various >projects that build on it >(http://fuse.sourceforge.net/filesystems.html) have >the potential to do a lot of what I had envisioned >LODNA doing. Therefore, I realize that there's >probably no need for yet another VFS framework ;) >Nevertheless, I think there is room for improvement >when it comes to giving users more flexibility in >mounting network locations (as described above). > >Thanks, >Vlad > >__ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > > > > - 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/
Re: reiser4 plugins
Neil Brown wrote: >On Tuesday July 12, [EMAIL PROTECTED] wrote: > > >>Neil Brown wrote: >> >> >> >>>Maybe it is worth repeating Al Viro's suggestion at this point. I >>>don't have a reference but the idea was basically that if you open >>>"/foo" and get filedescriptor N, then >>> /proc/self/fds/N-meta >>>is a directory which contains all the meta stuff for "/foo". >>>Then it is trivial to get the 'meta' stuff given a filedescriptor and >>>if you have a pathname, you can always get yourself a filedescriptor. >>> >>> >>> >>> >>This sound like it might be cute, but filedescriptors are too heavy >>weight for stat data accesses in quantity. >> >>In general, the whole file handle paradigm is too heavy for lightweight >>files. >> >> > >That may well be true, but is completely orthogonal to filesystem name >semantics. > >If you find file descriptors too slow, come up with an alternate (I >suspect you have in the reiser4 syscall, but I haven't looked at >that yet), implement it in the VFS, and show the world benchmarks of >real-world applications that go faster with this new interface. > >I doubt that you would then have a great deal of trouble in getting >the interface accepted (some trouble of course as you will need to >convince a few people, but numbers speak quite loudly). > >I suspect that there might need to be a new internal interface into >filesystems, and filesystems which don't provide that will not get the >same speed benefit, but that is perfectly acceptable. > >NeilBrown > > > > We need time, and then we can demonstrate sys_reiser4, it is not ready for showing yet. Hans - 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/
Re: Linux On-Demand Network Access (LODNA)
Peter Staubach wrote: > Vlad C. wrote: > >> --- Hans Reiser <[EMAIL PROTECTED]> wrote: >> >> >>> Please treat at greater length how your proposal >>> differs from NFS. >>> >> >> >> I think NFS is not flexible enough because: >> >> 1) NFS requires synchronization of passwd files or >> NIS/LDAP to authenticate users (which themselves >> require root access on both server and client to >> install) >> 2) NFS by definition understands only its own network >> protocol. >> 3) NFS requires root privileges on the client to >> mount. I'm not aware of a way to let normal users >> mount an NFS partition other than listing it in the >> client's fstab and adding the 'users' option... but >> then changing fstab still requires root access. >> 4) Users have to contact their sysadmin every time >> they want to mount a different partition, a different >> subdirectory of the same partition, or if they want to >> change the local mountpoint, all because the partition >> and mountpoint are hard-coded in fstab. >> >> On the other hand, I envision the following: >> > > Please keep in mind that these are restrictions of the current NFS > implementation and are not inherent in an NFS solution. > > The implied need for flexibility is being addressed by NFSv4 and the > ability to understand multiple versions of protocols and multiple > protocols is already resident in the system. We could do some work > to make it more transparent if desired, but it already works. > >Thanx... > > ps > > Peter, do you agree with his point that mounting should be something ordinary users can do on mountpoints they have write permission for? Do you agree that a systematic review of user friendliness would help NFS? Do you think that NFS should look at SFS and consider adopting some of its features? Hans - 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/
Re: Linux On-Demand Network Access (LODNA)
Peter Staubach wrote: > Hans Reiser wrote: > >> Peter, do you agree with his point that mounting should be something >> ordinary users can do on mountpoints they have write permission for? >> >> Do you agree that a systematic review of user friendliness would help >> NFS? Do you think that NFS should look at SFS and consider adopting >> some of its features? >> > > I think that connecting to required data could be more easily done than > currently. I don't know about allowing file systems to be mounted without > some form of control or resource utilization controls however. > > I do agree that the entire user experience associated with using and > trying > to administrate an NFS network could stand a good, long, hard look. > > Traditional tools such as the automounter were nice 15 years ago, but > have > not evolved with the world, nor have the rest of the system tools for > monitoring and managing NFS clients and servers. > > I could definitely envision better ways to handle things. In the past, > many of the arguments against making things better were security related. > There has been strong (relative term) security available to NFS > implementations > since 1997, but many vendors have not implemented it and many > customers found > it difficult to deploy because the underlying tools were very > difficult to > deploy. Many of the vendors are now implementing the security > framework, but > more work is required on the underlying security mechanisms, making them > easier to deploy. > > With proper security, usable monitoring and management tools, and > flexible > resource controls, then I wouldn't see why NFS mounts should be anything > special. > >Thanx... > > ps > > I would encourage you to look at SFS. it fixes a lot, making adding what Vlad asks for reasonable. - 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/
Re: reiser4 plugins
Hubert Chan wrote: >On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said: > > > >>Hubert Chan wrote: >> >> > > > >>>The main thing blocking file-as-dir is that there are some >>>locking(IIRC?) issues. And, of course, some people wouldn't want it >>>to be merged into the mainline kernel. (Of course, the latter >>>doesn't prevent Namesys from maintaining their own patches for people >>>to play around with.) >>> >>> > > > >>What's the locking issue? I think that was more about transactions... >> >> > >It was whatever was Al Viro's (technical) complaint about file-as-dir. >I don't remember exactly what it was. The technical people know what it >is (and the Namesys guys are probably working on it), and the exact >issue doesn't concern us non-technical people that much, so I don't feel >like looking it up. But if you want to, just look for Al Viro's message >in this thread. > > > Cycle detection when hard links to directories are allowed. There is a debate over whether cycle detection is feasible that can only be resolved by working code or a formal proof that it is not computationally feasible. Hans - 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/
Re: reiser4 plugins
David Masover wrote: >Hans Reiser wrote: > > >>Hubert Chan wrote: >> >> >> >> >>>On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said: >>> >>> >>> >>> >>> >>> >>>>Hubert Chan wrote: >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>>The main thing blocking file-as-dir is that there are some >>>>>locking(IIRC?) issues. And, of course, some people wouldn't want it >>>>>to be merged into the mainline kernel. (Of course, the latter >>>>>doesn't prevent Namesys from maintaining their own patches for people >>>>>to play around with.) >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >>>>What's the locking issue? I think that was more about transactions... >>>> >>>> >>>> >>>> >>>It was whatever was Al Viro's (technical) complaint about file-as-dir. >>>I don't remember exactly what it was. The technical people know what it >>>is (and the Namesys guys are probably working on it), and the exact >>>issue doesn't concern us non-technical people that much, so I don't feel >>>like looking it up. But if you want to, just look for Al Viro's message >>>in this thread. >>> >>> >>> >>> >>> >>Cycle detection when hard links to directories are allowed. There is a >>debate over whether cycle detection is feasible that can only be >>resolved by working code or a formal proof that it is not >>computationally feasible. >> >> > >Ah. But then, one solution was to avoid the issue at all, and have the >directory inside a file act as a mountpoint. After all, mount --bind >doesn't cause problems... > > Can you explain this idea at greater length? >Hey! This sounds like metafs (/meta) already! I wonder if we can do >file-as-dir in /meta, and just not support user-created hardlinks there? > (other than creating brand-new files, of course...) > > > > - 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/
Re: reiser4 plugins
David Masover wrote: >Now, can anyone think of a situation where we want user-created >hardlinks inside metadata? More importantly, what do we do about it? > > I think the equivalent of symlinks would be good enough to get by on for now for most linking of metafiles. Maybe some years from now somebody can fault me for saying this and write a patch to fix it to be better, at which point I will be happy to concede the point. So the basic principal here is, one can have hardlinks to directories without cycles provided that one does not allow any child of the directory to have a hardlink. The question is, how cleanly can that relaxed restriction be coded? Hans - 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/
Re: reiser4 plugins
I got it slightly wrong. One can have hardlinks to a directory without cycles provided that one does not have hardlinks from the children of that directory to any file not a child of that directory. (Mountpoints currently implement that restriction.) Question: can one implement that lesser restriction above with elegant code? Is the greater restriction below easier to code? (If no to the first and yes to the second is correct, then I can accept the greater restriction described below.) One can have hardlinks to directories without cycles provided that one does not allow any child of the directory to have a hardlink. Hans - 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/
Re: reiser4 plugins
If we also add to this the restriction that once you create the file part of a file-directory, you can never hardlink to a child of it, it should then all work, yes? So, /filename//owner should be able to avoid colliding with any common names by virtue of the '', and not letting any filedir (file-directory) have children with links to them should also work. The one thing that seems inelegant is that when you create the file part of a filedir, you must check all its children for hardlinks and fail if they exist, and you must flag all its directory children so that the plugins for them will disallow hardlinks to their children from that point onward. Still, seems workable Thanks David, Hans Hans Reiser wrote: >David Masover wrote: > > > >>Now, can anyone think of a situation where we want user-created >>hardlinks inside metadata? More importantly, what do we do about it? >> >> >> >> >I think the equivalent of symlinks would be good enough to get by on for >now for most linking of metafiles. Maybe some years from now somebody >can fault me for saying this and write a patch to fix it to be better, >at which point I will be happy to concede the point. > >So the basic principal here is, one can have hardlinks to directories >without cycles provided that one does not allow any child of the >directory to have a hardlink. The question is, how cleanly can that >relaxed restriction be coded? > >Hans > > > - 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/
Re: reiser4 plugins
Jeremy Maitin-Shepard wrote: >Okay, so you are suggesting that file-as-dir would provide the user >interface for enabling the encryption or compression. Alternatively, >though, an ioctl could be used to control compression and encryption. > > > Why is it that /proc does not use an ioctl? Use of metafiles could allow eliminating ioctl(), which most folks I know hate as an interface. Wouldn't it be cleaner if we could find out what ioctl()s are supported by a given file using ls filename//ioctl? Excerpt from the ioctl man page, which lacks a list of what features are implemented or how to find out. CONFORMING TO No single standard. Arguments, returns, and semantics of ioctl(2) vary according to the device driver in question (the call is used as a catch-all for operations that don't cleanly fit the Unix stream I/O model). See ioctl_list(2) for a list of many of the known ioctl calls. The ioctl function call appeared in Version 7 AT&T Unix. - 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/
Re: reiser4 plugins
Hubert Chan wrote: >On Tue, 05 Jul 2005 20:50:08 -0400 EDT, "Alexander G. M. Smith" <[EMAIL >PROTECTED]> said: > > > >>That sounds equivalent to no hard links (other than the usual parent >>directory one). If there's any directory with two links to it, then >>there will be a cycle somewhere! >> >> > >What we want is no directed cycles. That is A is the parent of B is the >parent of C is the parent of A. We don't care about A is the parent of >B is the parent of C; A is the parent of B is the parent of C. > >OK, here's a random idea that just popped into my head, and to which >I've given little thought (read: none whatsoever), and may be the >stupidest idea ever proposed on LKML, but thought I would just toss it >out to see if it could stimulate someone to come up with something >better (read: sane): Conceptually, foo/ is just a symlink to >/meta/[filesystem]/[inode of foo]. > > Except that we want the metafiles to go away when the base file goes away. >And a question: is it feasible to store, for each inode, its parent(s), >instead of just the hard link count? > > Ooh, now that is an interesting old idea I haven't considered in 20 years makes fsck more robust too - 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/
Re: reiser4 plugins
Martin Waitz wrote: >hoi :) > >On Tue, Jul 05, 2005 at 04:32:00PM -0600, Jonathan Briggs wrote: > > >>You could do filesystems in userspace too and just use the kernel's >>block layer. >> >> > >but you can't do that in an library, you have to use a filesystem >server in order to get access control. >But you can build a library that handles uniform access to >files and directories. > >Don't get me wrong, I'm all for a uniform interface for files and >metadata, but I don't think that it has to be in the kernel. >Gnome and KDE already have their own userspace VFS, something >like that should be used. > >One has to distinguish between the low-level filesystem and >the storage system which is presented to the user. > > > Yes, but to do what you advocate properly, the existing semantics currently in the kernel should be moved out of it into user space. I think the exokernel approach by Frans is a very interesting approach. I wish I had the experience with it necessary to know if it was effective. I do NOT take the position that name resolution should be in the kernel. I DO take the position that it should be either in the kernel or out of the kernel, and should constitute one cohesive and coherent body of code. If someone talks Linus into trying the exokernel approach, I will be happy to educate myself to where I have an opinion on whether that works. It is easy to see powerful advantages to the exokernel approach: I wish I understood the security model for it, and I wish I was sure that name resolution would not require too many context switches as one fetches each storage component required by a name resolution. Masover's words about HURD earlier in this thread were very well said. Context switching is expensive, and I find it easier to be sure my code will both perform well and be cohesive if it is all done in the kernel by one body of code. - 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/
Re: reiser4 plugins
David Masover wrote: > So, will the format change happen at mount time? Will it need a > special mount flag? Will I need to use debugfs or some other offline > tool? First we make sure we have the right answer. Have we solved the cycle problem? Can we run out of memory as Horst/Nikita suggest? - 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/
Re: reiser4 plugins
Nate Diller wrote: > > > as an example, if a program were to store some things it needs access > to in its executable's attributes, it should have the option of > keeping a hard reference to something, so that it can't be deleted out > from underneath. this enables sane sharing of resources without > ownership tracking problems (see windows DLL hell for details). the > attribute space should be indistinguishable from the rest of the > namespace, and should be able to link (soft or hard) anywhere in the > FS. anything less is too much work for too little reward. > You already have a problem with hardlinks not crossing mount points, but I understand your point. If we can write code for solving the cycle problem cleanly, it would be best. - 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/
Re: reiser4 plugins
David Masover wrote: > And, once we start talking about applications, /meta will be more > readily supported (as in, some apps will go through a pathname and > stop when they get to a file, and then there's tar). On apps which > don't have direct support for /meta, you'd be navigating to the file > in question and then manually typing '...' into the dialog, so I don't > see why typing '...' at the end is better than typing '/meta' or > '/meta/vfs' at the beginning. Performance. If you type it at the end, and you already have done the lookup of the filename, then you can go from the file to one of its methods, instead of a complete new traversal of another tree under /meta > > That said, I'm still not entirely sure how we get /meta/vfs to work > other than adding a '...' sort of delimiter anyway. > >>> And a question: is it feasible to store, for each inode, its parent(s), >>> instead of just the hard link count? >>> >>> >> >> Ooh, now that is an interesting old idea I haven't considered in 20 >> years makes fsck more robust too > > > Doesn't it make directory operations slower, too? Not sure. It consumes space though. > > And, will it require a format change? > Yes, but we have plugins now, so. - 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/
Re: reiser4 plugins
Horst von Brand wrote: >Hans Reiser <[EMAIL PROTECTED]> wrote: > >[...] > > > >>I think the exokernel approach by Frans is a very interesting approach. >>I wish I had the experience with it necessary to know if it was >>effective. I do NOT take the position that name resolution should be in >>the kernel. I DO take the position that it should be either in the >>kernel or out of the kernel, and should constitute one cohesive and >>coherent body of code. >> >> > >Right. > > > >>If someone talks Linus into trying the exokernel >>approach, >> >> > >Are you nuts?! Such radical experiments do /not/ belong in the kernel on >which millions of machines depend! > > Your response is a flame, and I will not respond to it. - 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/
Re: reiser4 plugins
Jonathan Briggs wrote: >On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote: > > >>Hubert Chan wrote: >> >> >>>And a question: is it feasible to store, for each inode, its parent(s), >>>instead of just the hard link count? >>> >>> >>> >>> >>Ooh, now that is an interesting old idea I haven't considered in 20 >>years makes fsck more robust too >> >> > >Hey, sounds like the idea I proposed a couple months ago of storing the >path names in each file, instead of in directories. Only better, since >each path component isn't text but a link instead. > >It still has the performance and locking problem of having to update >every child file when moving a directory tree to a new parent. On the >other hand, maybe the benefit is worth the cost. > > Oh no, don't store the whole path, store just the parent list. This will make fsck more robust in the event that the directory gets clobbered by hardware error. I don't think it affects the cost of detecting cycles though, I think it only makes fsck more robust. Hans - 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/
Re: reiser4 vs politics: linux misses out again
David Lang wrote: > > remember that Hans is on record (over a year ago) arguing that R3 > should not be fixed becouse R4 was replacing it. No, I said and say that V3 should not have features added to it, because features should not be added to a stable branch. Bug fixes are good. There are a few V3 bug fixes where the fix is so deep that it belongs in V4, all of the ones that I can think of at the moment are ones requiring disk format changes. Note that in V4, disk format changes are no longer deep fixes because of plugins. > > This type of thing is one of the reasons that you see arguments that > aren't 'purely code-related' becouse the kernel folks realize that > _they_ will have to maintain the code over time, Hans and company will > go on and develop R5 (R10, whatever) and consider R4 obsolete and stop > maintaining it. No, we will stop adding features to it at some point, only add bug fixes, and let it become stable enough for mission critical use. Of course, with plugins this becomes more complicated of a policy because smaller releases with more orthogonal features are easier and more tempting, and it becomes tempting to version and release plugins rather than the FS, so I am not sure exactly how this will play out yet. I think we will have an option to select experimental plugins individually. > > David Lang > - 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/
Re: reiser4 vs politics: linux misses out again
Ed Tomlinson wrote: >On Sunday 10 July 2005 01:10, Horst von Brand wrote: > > >>Ed Cogburn <[EMAIL PROTECTED]> wrote: >> >> >>>David Lang wrote: >>> >>> On Fri, 8 Jul 2005, Ed Tomlinson wrote: >No Flame from me. One thing to remember is that Hans and friends >_have_ supported R3 for years. > > >>They let it fall into disrepair when they started work on 4. >> >> > >This is FUD. Hans do you have figures on how many fixes for R3 have >been added in the last year or so? > > No, but I can tell you that > 2/3 were related to features I thought should have been put in V4 instead, and were added in violation of my declared code freeze and without my consent. Naturally, those bugs were routed to the authors of those features. There were maybe 2 bugs in the last 18 months in code not related to code freeze violations, I don't remember exactly. There is a simple reason why Namesys no longer spends much time on bug fixes for V3. The frozen code is too stable to generate bug reports to work on, and the unfrozen code is not ours. If the unfrozen code stopped being maintained, I'd have to do something. It seems to me that you should all hope that V4 gets to where Namesys does not spend much time maintaining it. It means we have no bug reports. Stable branches, and development branches, and only bug fixes get added to the stable branch, it is an old paradigm, and broadly speaking it is still the right paradigm. Guys, Horst is trolling.He has never used our code, and yet. - 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/
Re: [PATCH 00/14] GFS
Arjan van de Ven wrote: >On Tue, 2005-08-02 at 16:57 +0200, Jan Engelhardt wrote: > > >>>* Why use your own journalling layer and not say ... jbd ? >>> >>> >>Why does reiser use its own journalling layer and not say ... jbd ? >> >> > >because reiser got merged before jbd. Next question. > > That is the wrong reason. We use our own journaling layer for the reason that Vivaldi used his own melody. I don't know anything about GFS, but expecting a filesystem author to use a journaling layer he does not want to is a bit arrogant. Now, if you got into details, and said jbd does X, Y and Z, and GFS does the same X and Y, and does not do Z as well as jbd, that would be a more serious comment. He might want to look at how reiser4 does wandering logs instead of using jbd. but I would never claim that for sure some other author should be expected to use it. and something like changing one's journaling system is not something to do just before a merge. >Now the question for GFS is still a valid one; there might be reasons to >not use it (which is fair enough) but if there's no real reason then >using jdb sounds a lot better given it's maturity (and it is used by 2 >filesystems in -mm already). > > > >- >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/ > > > > - 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/
Re: RFC: i386: kill !4KSTACKS
Adrian Bunk wrote: >4Kb kernel stacks are the future on i386, and it seems the problems it >initially caused are now sorted out. > >Does anyone knows about any currently unsolved problems? > >I'd like to: >- get a patch into on of the next -mm kernels that unconditionally > enables 4KSTACKS >- if there won't be new reports of breakages, send a patch to > completely remove !4KSTACKS for 2.6.15 > >In -mm, Reiser4 still has a dependency on !4KSTACKS. >I've mentioned this at least twice to the Reiser4 people, and they >should check why this dependency is still there and if there are still >stack issues in Reiser4 fix them. > >If not people using Reiser4 on i386 will have to decide whether to >switch the filesystem or the architecture... > >cu >Adrian > > > Can you wait just one month after we get in for this? Or even 2 weeks. vs needs a weekend, etc. - 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/
Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
Adrian Bunk wrote: >Hi Hans, > >REISER4_FS is the only option with a dependency on !4KSTACKS which is >bad since 8 kB stacks on i386 won't stay forever. > >Could fix the problems with 4 kB stacks? > >Running > > make checkstacks | grep reiser4 > >inside te kernel sources after compiling gives you hints where problems >might come from. > > >TIA >Adrian > > > All of my technical arguments on this topic were nicely obliterated by Andrew. The only real reason remaining (that I know of) is that I want to first eliminate all things which are a barrier to inclusion before dealing with this because it requires man hours to fix it. If you want to send us a cleanup patch that fixes it, I would be grateful for your time donatioin. Hans - 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/
Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
Adrian Bunk wrote: >On Tue, Mar 22, 2005 at 09:50:14AM -0800, Hans Reiser wrote: > > > >>All of my technical arguments on this topic were nicely obliterated by >>Andrew. The only real reason remaining (that I know of) is that I want >>to first eliminate all things which are a barrier to inclusion before >>dealing with this because it requires man hours to fix it. If you want >>to send us a cleanup patch that fixes it, I would be grateful for your >>time donatioin. >> >> > >My plan is to send a patch to Andrew that unconditionally enables >4KSTACKS for shaking out the last bugs before possibly removing >8 kB stacks completely. > >I don't know whether this is barrier to inclusion, but this will make >reiser4 unavailable on i386... > > > >>Hans >> >> > >cu >Adrian > > > Sigh. Could you wait a few weeks until we have done all the other things, and then I can have Vladimir work with you on it? - 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/
Re: 2.6.11-rc3-mm1 bad scheduling while atomic + lockup
Maciej Soltysiak wrote:
)
Feb 6 17:07:47 dns kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Feb 6 17:07:47 dns kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
this means bad hard drive, or at least a bad sector on it.
-
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/
Re: directory order of files
Edmund GRIMLEY EVANS wrote: > > With Linux ext2, and some other systems, when you create files in a > new directory, the file system remembers their order: > > $ mkdir new > $ cd new > $ touch one two three four > $ ls -U > one two three four > > (1) Is there any standard that says a system should behave this way? > Is there any software that depends on this behaviour? Unix filesystem hierarchies are defined to be a partial ordering, not a full ordering. > > (2) Are there Linux file systems that don't work this way? Maybe > someone with a mounted writable reiserfs could do a quick check. > > Please copy replies to me as I am not subscribed. Thanks. bash-2.05# mkdir fu bash-2.05# cd fu bash-2.05# touch one two three four bash-2.05# ls -U one two four three Hans - 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/
Re: NFS Client patch
Trond Myklebust wrote: > > > " " == Chris Mason <[EMAIL PROTECTED]> writes: > > > Well, returning the last filename won't do much for filesystems > > that don't have any directory indexes, but that's besides the > > point. Could nfsv4 be better than it is? probably. Can we > > change older NFS protocols to have a linux specific hack that > > makes them more filesystem (or at least reiserfs) friendly? > > probably. > > NFSv2 and v3 have a fixed format for readdir calls. There's bugger all > you can do to change this without making the resulting protocol > incompatible with NFS. > > If you don't want Reiserfs to be NFS compatible, then fine, but I > personally don't want to see hacks to the NFS v2/v3 code that rely on > 'hidden knowledge' of the filesystem on the server. > > Cheers, > Trond > - > 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/ The current code does rely on hidden knowledge of the filesytem on the server, and refuses to operate with any FS that does not describe a position in a directory as an offset or hash that fits into 32 or 64 bits. But be calm, I am not planning on fixing this myself anytime in the next year, we have an ugly and hideous hack deployed in ReiserFS that works, for now I am just saying the folks who designed NFS did a bad job and resolutely continue doing a bad job, and if someone wanted to fix it, they could fix cookies to use filenames instead of byte offsets for those filesytems able to better use filenames than byte offsets to describe a position within a directory, and for those clients and servers who are both smart enough to understand filenames instead of cookies (able to understand the cookie monster protocol). Hans - 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/
Re: NFS Client patch
Trond Myklebust wrote: > > >>>>> " " == Hans Reiser <[EMAIL PROTECTED]> writes: > > > The current code does rely on hidden knowledge of the filesytem > > on the server, and refuses to operate with any FS that does not > > describe a position in a directory as an offset or hash that > > fits into 32 or 64 bits. > > I'm not saying that ReiserFS is wrong to question the correctness of > this. I'm just saying that NFSv2 and v3 are fixed protocols, and that > it's too late to do anything about them. I read Chris mail as a > suggestion of creating yet another NQNFS, and this would IMHO be a > mistake. Better to concentrate on NFSv4 which is meant to be > extendible. > > > But be calm, I am not planning on fixing this myself anytime in > > the next year, we have an ugly and hideous hack deployed in > > ReiserFS that works, for now I am just saying the folks who > > designed NFS did a bad job and resolutely continue doing a bad > > job, and if someone wanted to fix it, they could fix cookies to > > use filenames instead of byte offsets for those filesytems able > > to better use filenames than byte offsets to describe a > > position within a directory, and for those clients and servers > > who are both smart enough to understand filenames instead of > > cookies (able to understand the cookie monster protocol). > > This is something which I believe you raised in the NFSv4 group, and > which could indeed be a candidate for an NFSv4 extension. After all, > this is in essence a recognition of the method most NFS clients > implement for recovering from an EBADCOOKIE error. Why was the idea > dropped? Lack of desire to do anything, near as I could tell. > > (Note: As I said, under Linux we're currently hampered when > considering the above alternatives by the fact that glibc requires the > ability to lseek() on directories. This is a bug that they could > easily fix, and it affects not only your suggestion, but also all the > other suggestions in which one implements non-permanent cookies) I would be quite happy if you (or anyone) could fix it, sometime in the next 3 years. > > Cheers, >Trond - 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/
Re: Security hooks, "standard linux security" & embedded use
Hi Linda, This seems very much in line with what Reiser4 is doing for DARPA, and what SE Linux is doing for the NSA. Or at least what Linus told the SE Linux folks he would like them to write.:-) I am quite supportive of what you advocate generally, and I look forward to cooperating with you in the details. May I suggest we contact the SE Linux folks, and each of our teams establish a point-of-contact to work on developing the details of what needs to be done? We call your security hooks "security plugins" or "secplugs" in Reiser4, mostly to identify that they are a component of the Reiser4 "plugin" approach to extensibility. Reiser4 is getting underway this month. We are willing to adapt our terminology and coding to be be consistent with yours. We don't really have a need to be the leaders in this area. We just need to get the job done, and to ensure that nothing that is done crimps our ability to accomplish our objectives. Our project objectives are somewhat describable as "make it easy for folks like the NSA and the DoD to add new security features to Reiser4 by building the infrastructure for them." We will ship one implementation on top of that infrastructure that will implement ACLs, but we are more interested in enabling others than in doing ourselves. If the NSA or SGI wants to lead us a bit on this, that is fine with us. Our main insistence is going to be that the hooks should be very general, but I suspect you and the NSA also want that. We also need to have coding completed in ~8 months, so that it can all be debugged and stable and sent to Linus by Sep. 30th of next year. Do you have a list of all the hooks, etc., yet? Do you have anything like a general architecture for, given some vfs operation, and given some pluginid indicating object type, and given some secplugid (e.g. it might be the id of a secplug implementing an ACL), have the plugin check that the operation is allowable by calling the secplug (security hook) indicated by the secplugid? I think what is needed is an MxN matrix of security checks, where M is the number of vfs operations, and N is the number of secplugs. I am open to the idea that it should be MxNxO, where O is the number of security policies, though I don't plan to personally implement more than one security policy to ship with Reiser4 by default because I am pretty lazy. It won't surprise me if I end up shipping only one secplug with reiser4 initially (probably one implementing something embodying NT ACLs and unix permissions), and leave it to others to add the rest of them). I am quite supportive of your notion that some users have no need at all for security, and that they should be allowed a lightweight solution for their needs, though I will leave it to them to write that on top of the infrastructure I/we give them.:-) I envision the VFS operation invoking the plugin which invokes the secplug whose implementation varies with the choice of security policy compiled in. I don't honestly see the real usage critical need for dynamic loading of security policy modules, but I can yield on this if you see the need and code it since it probably isn't complex to code. I do like the idea of all of the code implementing a given security policy being isolated into its own single file/directory. Do you have any ideas on how to export to user space the ability to query what the permissions are, given that the permissions are being abstracted like this? I got your email, but I wasn't on the to: or cc: list. This confused me, so I invented a to: list that should reach all those likely to be interested in this. I am guessing this will be okay with you. Best, Hans LA Walsh wrote: > > Dear Linus et al., > > Sorry for the 'form' letter instead of individual names, but I > didn't want to have to send this out separately to every kernel developer > I know on LKML. > > I am asking for your input on the concept of moving the standard > Linux security checks into a "Linux Security Module". > > Discussion has come up on the Linux Security Module list > about whether or not the current linux security (file mode bits, uid > checking, etc.) should be modularized in the development of an LSM > framework implementation > > This would entail moving all of the standard checks out of the > kernel into a "standard security" module that, by default, would be > the security policy selected and compiled in during kernel configuration > and build. > > This seems to us (@sgi) to be the best solution to allow a > completely configurable security policy. This option allows > a policy creator complete flexibility in how or whether or not > existing security is called. For example, in POSIX 1e style Mandatory > Access Control, the information in the inode is also part of the > protected object. So if a process doesn't have access under MAC, the > DAC checks wouldn't even be executed since it d
[reiserfs-list] Re: [reiserfs-dev] Re: Note describing poor dcache utilization under high memory pressure
Oliver Xymoron wrote: > >Can we get you to agree that basically all subpage objects are immovable? > No. Certainly not in the general case, and I think Josh found ways to handle the dcache case. If we can simply free the old objects, we don't actually have to move the hot ones, as he points out. > >And as a consequence that garbage collecting at subpage levels doesn't >guarantee freeing up any pages that can then be given up to other >subsystems in response to VM pressure? The GC must think in terms of pages >to actually make progress. > >One of the design goals of slab by the way is that objects of a similar >type will end up having similar lifetimes, avoiding some of the worst >cases of sub-page allocations. > - 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/
