search for: mountainviewdata

Hi, We hit an interesting issue with Ext3 in ordered data mode. A large file was truncated (open with O_TRUNC) and immediately over-written with a single write call. The write call returned ENOSPACE, but a check for space (using essentially statfs) promised that there would be plenty of space. The reason turned out to be that the blocks freed by the truncation were not yet available to the

Is there any way (short of not patching it into the kernel) to turn KDB off on a given machine? There are some machines I do not want dropping into kdb when/if it oopses. Thanx, b.

Im intending use Ext3 file system in my web farm. Im using RedHat 6.2 (kernel 2.2.16-3) and Turbo Linux Cluster Server 6.0. I have NO SUCCESS in path my own kernel. I downloaded the following ext3 packages: ext3-0.0.2f.tar.gz (linux-2.2.16-3.kdb.diff , linux-2.2.16-3.ext3.diff ) e2fsprogs-1.20-0.WIP.i386.rpm e2fsprogs-1.20-0.WIP.src.rpm e2fsprogs-1.20-0ext3.i386.rpm

---------- Forwarded Message ---------- Subject: ext3 for 2.4 Date: Thu, 17 May 2001 21:20:38 +1000 From: Andrew Morton <andrewm@uow.edu.au> To: ext2-devel@lists.sourceforge.net, "Peter J. Braam" <braam@mountainviewdata.com>, Andreas Dilger <adilger@turbolinux.com>, "Stephen C. Tweedie" <sct@redhat.com> Cc: linux-fsdevel@vger.kernel.org Summary: ext3 works, page_launder() doesn't :) The tree is based on the porting work which Peter Braam did. It's in cvs in Jeff Garzik's...

As previously mentioned on the lists by Olle Johannson, we are actively trying to get Asterisk in shape for a 1.2 release within the next 60 days. To accomplish this, we need a few things to happen: 1) A feature freeze - This will occur at the end of this month, with no new feature submissions accepted after July 31st. Any _pending_ feature patches in Mantis that have passed architecture

...oes in the middle. This seems somewhat suspicious, but it's likely that I'm not understanding everything about ext3. Thanks for clarifying the situation. - Peter - -----Original Message----- From: Aaron Smith [mailto:aaron@fry.dyn.us.mvd] Sent: Monday, March 12, 2001 5:50 PM To: braam@mountainviewdata.com Subject: /* * Intermezzo. (C) 1998 Peter J. Braam */ #include <linux/types.h> #include <linux/kernel.h> #include <linux/fs.h> #include <linux/malloc.h> #include <linux/vmalloc.h> #include <linux/time.h> #include <linux/errno.h> #include <linux/l...

Hi Andreas, Stephen, We have a lot working now: 1. journal recovery and initialization stuff is working 2. transactions go to the disk 3. infrastructure is there to do transcactions 4. ext3_create is fully operational. The problems we have seen mostly have to do with differences in which buffer heads are being initialized. Things like b_transaction etc. were not cleaned up. There are more

[ Tried to check the archives but the website seems to be down or something ] On one of our installations, I am seeing messages such as: EXT3-fs warning (device ide0(3,9))): ext3_free_inode: bit already clearned for inode 14 Anybody know exactly what they mean? These would be on a 0.0.6a system. b.

Hi, Arthur found out that ext3 is not changing the ctime on the "old_dir" (the object that is being renamed), but ext2 does. It looks to me like this is simply an omission of the following little patch from namei.c - Peter - --- fs/ext3/namei.c.orig Mon Mar 19 22:55:03 2001 +++ fs/ext3/namei.c Mon Mar 19 22:53:40 2001 @@ -985,6 +985,13 @@ new_dir->i_version =

One of our users here got the following with an ext3 0.0.6b: # debugfs /dev/hda3 debugfs 1.20-WIP, 17-Jan-2001 for EXT2 FS 0.5b, 95/08/09 /dev/hda3: Bad magic number in super-block while opening filesystem debugfs: Does debugfs need updating? b.

Hi Stephen, I'm one of developers of SnapFS, which based on Ext3. I got Assertion failure from SnapFS, at ext3_new_block() in fs/ext3/balloc.c: J_ASSERT (!test_and_set_bit(BH_Alloced, &bh->b_state)) If J_ASSERT is only use as debug, why it will modify data? I found the 'BH_Alloced' flag only occures at two place: one is balloc.c as above, the other is at journal_forget() in

Hi, I noticed that using a sparse file as a loop device leads to non journaled block allocation in Ext3. Is this something that should be fixed? - Peter -

Hi Stephen, We had some starvation/locks happening to us under very heavy load in two cases: - InterMezzo asked ext3 to do a journaled file write (for 1 block) essentially using ext3_write - similarly for truncate. These lockups went away when we started the transaction in InterMezzo and reserved somewhat more space than ext3 does. Any clues as to what this might be? Are the ext3

Anyone know? The just released RedHat 2.2.17-14 kernel has an ext3/kdb patch in it. Any idea which ext3 release it is? b. -- Brian J. Murrell

Hi samba guys, I'm useing samba 2.2.3a (XFS/Linux W2k), and I found inconsisten behavior responsed to default ACL. The test is: 1> Create a direcotry named "share" from linux local. 2> Add default ACL to "share". 3> Touch new file "flinux"/make new directory "dlinux" under "share" from linux local. 4> Create new file

Hi, I've very strange problem from my cumtomer, his step is: 1. create a samba share, with sync always=no and strict sync=no 2. coping some big files 3. reboot, repeat step 2, he saw the performance is very bad 4. set sync always and strict sync to yes, repeat step 2, the performance is more better than step 3 I think this is maybe because of network traffic, but my customer dosn't

Doing some debugging of my kernel build with ext3 and noticed something interesting. At the bottom of the rootflags options processing loop there is a return failure if there was an option that ext3 did not know about. Should this be the behaviour? Would it not be better to ignore options not recognized? Surely, some day, some other filesystem is going to want to use rootflags to have one of

I want to convert the last of my filesystems to ext3. The only one left is /boot. It is not very big however, only about 10MB itself. Any recommendations on what size journal to put a /boot filesystem of only 10-20MB? Oh, BTW: "tunefs -j -J size=..." is awesome. No more gyrations with dd, chattr, lilo -R, etc. Nice! One note however: even in Stephen's 1.20.WIP.sct-20010216

Hello all, I am trying to integerate 0.0.6b with our kernel RPM here and have come across an interesting conflict. I want to include the raid patch that Red Hat includes in their kernel but that patch includes the following hunk: --- linux/include/linux/fs.h.orig Tue Jan 16 13:30:09 2001 +++ linux/include/linux/fs.h Tue Jan 16 13:47:18 2001 @@ -191,6 +191,7 @@ #define BH_Req 3 /* 0 if the

I updated my kernel from 0.0.3d to 0.0.3e using the "d-e" patch in the 0.0.3e tarball. When I try to boot the new kernel on a machine with an ext3 root filesystem I am getting the message: JFS: Unrecognised features on journal Does this sound feasible or even somewhat expected? Is there any interest in me doing some debugging of this? Is there any way to deal with this without