Re: Using cramfs as root filesystem on diskless machine
Alexandr Andreev wrote: > > David L. Parsley wrote: > > >Mathias Killian wrote a patch to allow cramfs initrd's, see: > >http://www.cs.helsinki.fi/linux/linux-kernel/2001-01/1064.html > > > Thank you. I applied this patch, and recompiled my kernel. > All works fine, if the size of root filesystem less than 4096Kb. But > when i create > an image of root filesystem which size is bigger than 4096Mb, the kernel > said: > ... > RAMDISK driver initialized: 16 RAM disks of 4096K size 4096 blocksize ^ You also need to give the kernel 'ramdisk_size='. I've used larger cramfs initrd's with no problem, but the kernel has to make larger ramdisks. By editing rd.c, you can make this stuff default. regards, David -- David L. Parsley Network Administrator, Roanoke College "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton - 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: Using cramfs as root filesystem on diskless machine
Alexandr Andreev wrote: David L. Parsley wrote: Mathias Killian wrote a patch to allow cramfs initrd's, see: http://www.cs.helsinki.fi/linux/linux-kernel/2001-01/1064.html Thank you. I applied this patch, and recompiled my kernel. All works fine, if the size of root filesystem less than 4096Kb. But when i create an image of root filesystem which size is bigger than 4096Mb, the kernel said: ... RAMDISK driver initialized: 16 RAM disks of 4096K size 4096 blocksize ^ You also need to give the kernel 'ramdisk_size='. I've used larger cramfs initrd's with no problem, but the kernel has to make larger ramdisks. By editing rd.c, you can make this stuff default. regards, David -- David L. Parsley Network Administrator, Roanoke College If I have seen further it is by standing on ye shoulders of Giants. --Isaac Newton - 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: Using cramfs as root filesystem on diskless machine
Mathias Killian wrote a patch to allow cramfs initrd's, see: http://www.cs.helsinki.fi/linux/linux-kernel/2001-01/1064.html Alexandr Andreev wrote: > > Hi, list. > > My MIPS machine has no any disks or flopies. So i obliged to use a RAM > disk with a file system on it, which is mounted as root. > I use gzipped initrd image, which is linked to the special section in the > kernel during compilation. Now, the RAM disk size is really big, so i > decide > to use cramfs instead of ext2. In scripts/cramfs/ I found an utility that > creates cramfs file system image. But i read in rd.c, that RAM disk driver > doesn't support the cramfs. > > After i create an image, how can i mount it as root file system? Where i > must put it? Which kernel command line options i must use? > > Please answer, or point me to any documentation or mailing list. > > - > 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/ -- David L. Parsley Network Administrator, Roanoke College "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton - 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: Using cramfs as root filesystem on diskless machine
Mathias Killian wrote a patch to allow cramfs initrd's, see: http://www.cs.helsinki.fi/linux/linux-kernel/2001-01/1064.html Alexandr Andreev wrote: Hi, list. My MIPS machine has no any disks or flopies. So i obliged to use a RAM disk with a file system on it, which is mounted as root. I use gzipped initrd image, which is linked to the special section in the kernel during compilation. Now, the RAM disk size is really big, so i decide to use cramfs instead of ext2. In scripts/cramfs/ I found an utility that creates cramfs file system image. But i read in rd.c, that RAM disk driver doesn't support the cramfs. After i create an image, how can i mount it as root file system? Where i must put it? Which kernel command line options i must use? Please answer, or point me to any documentation or mailing list. - 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/ -- David L. Parsley Network Administrator, Roanoke College If I have seen further it is by standing on ye shoulders of Giants. --Isaac Newton - 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: [CFT][PATCH] namespaces patch (2.4.5-pre6)
Alexander Viro wrote: > > Folks, new version of the patch is on > ftp.math.psu.edu/pub/viro/namespaces-c-S5-pre6.gz > > News: > * ported to 2.4.5-pre6 > * new (cleaner) locking mechanism > * lock_super() is starting to become fs-private thing - first steps to > removing it from VFS code are done. > > Please, help with testing. I'm feeding the pieces suitable for 2.4 into > the Linus' tree, so patch got smaller. OK, at the risk of asking a Stupid Question (tm), what exactly does the namespaces patch buy us? From the viewpoint of an integrator/system admin? I'd happily check it out if I thought it would solve any of the problems I regularly see. regards, David -- David L. Parsley Network Administrator, Roanoke College "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton - 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: [CFT][PATCH] namespaces patch (2.4.5-pre6)
Alexander Viro wrote: Folks, new version of the patch is on ftp.math.psu.edu/pub/viro/namespaces-c-S5-pre6.gz News: * ported to 2.4.5-pre6 * new (cleaner) locking mechanism * lock_super() is starting to become fs-private thing - first steps to removing it from VFS code are done. Please, help with testing. I'm feeding the pieces suitable for 2.4 into the Linus' tree, so patch got smaller. OK, at the risk of asking a Stupid Question (tm), what exactly does the namespaces patch buy us? From the viewpoint of an integrator/system admin? I'd happily check it out if I thought it would solve any of the problems I regularly see. regards, David -- David L. Parsley Network Administrator, Roanoke College If I have seen further it is by standing on ye shoulders of Giants. --Isaac Newton - 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] rootfs (part 1)
Linus Torvalds wrote: > What the hell are you doing? Compiling with debugging or something? I'll bet he's using a rootkit 'ls' that shows file sizes in bits. ;-) regards, David -- David L. Parsley Network Administrator, Roanoke College "If I have seen further it is by standing on ye shoulders of Giants." --Isaac Newton - 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] rootfs (part 1)
Linus Torvalds wrote: What the hell are you doing? Compiling with debugging or something? I'll bet he's using a rootkit 'ls' that shows file sizes in bits. ;-) regards, David -- David L. Parsley Network Administrator, Roanoke College If I have seen further it is by standing on ye shoulders of Giants. --Isaac Newton - 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: ramdisk/tmpfs/ramfs/memfs ?
David Woodhouse wrote: > Why copy it into RAM? Why not use cramfs and either turn the writable > directories into symlinks into a ramfs which you create at boot time, or > union-mount a ramfs over the top of it? ^^^ I didn't think we had union-mounting support... does it exist and I've somehow missed it? regards, David -- David L. Parsley Network Administrator Roanoke College - 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: hundreds of mount --bind mountpoints?
Christoph Rohland wrote: > > OK I will do that for tmpfs soon. And I will do the symlink inlining > with that patch. Wow, this thread really exploded, eh? But thanks, Christoph, I look forward to seeing your patch. 4k symlinks really suck for embedders who never swap out pages. ;-) regards, David -- David L. Parsley Network Administrator Roanoke College - 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: hundreds of mount --bind mountpoints?
Christoph Rohland wrote: OK I will do that for tmpfs soon. And I will do the symlink inlining with that patch. Wow, this thread really exploded, eh? But thanks, Christoph, I look forward to seeing your patch. 4k symlinks really suck for embedders who never swap out pages. ;-) regards, David -- David L. Parsley Network Administrator Roanoke College - 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: hundreds of mount --bind mountpoints?
Christoph Rohland wrote: > > Hi David, > > On Sun, 22 Apr 2001, David L. Parsley wrote: > > I'm still working on a packaging system for diskless > > (quasi-embedded) devices. The root filesystem is all tmpfs, and I > > attach packages inside it. Since symlinks in a tmpfs filesystem > > cost 4k each (ouch!), I'm considering using mount --bind for > > everything. > > What about fixing tmpfs instead? That would be great - are you volunteering? ;-) Seriously - I might be able to look at what ramfs does and port that to tmpfs for my needs, but that's about the extent of my kernel hacking skills. For now, mount --bind looks like it'll work just fine. If somebody wants to fix tmpfs, I'll be happy to test patches; it'll just change a couple of lines in my package loading logic (mount --bind x y -> ln -s x y). What I'm not sure of is which solution is actually 'better' - I'm guessing that performance-wise, neither will make a noticable difference, so I guess memory usage would be the deciding factor. If I can get a lot closer to the size of a symlink (10-20 bytes) that would be best. The issue with /proc/mounts really shouldn't hurt anything - I could almost get by without mounting /proc anyway, it's mainly a convenience. regards, David -- David L. Parsley Network Administrator Roanoke College - 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/
hundreds of mount --bind mountpoints?
Hi, I'm still working on a packaging system for diskless (quasi-embedded) devices. The root filesystem is all tmpfs, and I attach packages inside it. Since symlinks in a tmpfs filesystem cost 4k each (ouch!), I'm considering using mount --bind for everything. This appears to use very little memory, but I'm wondering if I'll run into problems when I start having many hundreds of bind mountings. Any feel for this? regards, David -- David L. Parsley Roanoke College Network Administrator - 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/
hundreds of mount --bind mountpoints?
Hi, I'm still working on a packaging system for diskless (quasi-embedded) devices. The root filesystem is all tmpfs, and I attach packages inside it. Since symlinks in a tmpfs filesystem cost 4k each (ouch!), I'm considering using mount --bind for everything. This appears to use very little memory, but I'm wondering if I'll run into problems when I start having many hundreds of bind mountings. Any feel for this? regards, David -- David L. Parsley Roanoke College Network Administrator - 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/
union mounting?
Hi Alex, I'm working on an embedded distro, and it would be nice if I could just mount 'packages' over the top of one another; each 'package' is a cramfs filesystem. I'm currently using a bunch of symlink stuff, but it's not real pretty. If you've got union mounting patches for testing, I'd be interested. ;-) regards, David -- David L. Parsley Network Administrator Roanoke College - 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/
union mounting?
Hi Alex, I'm working on an embedded distro, and it would be nice if I could just mount 'packages' over the top of one another; each 'package' is a cramfs filesystem. I'm currently using a bunch of symlink stuff, but it's not real pretty. If you've got union mounting patches for testing, I'd be interested. ;-) regards, David -- David L. Parsley Network Administrator Roanoke College - 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/
/proc/sys/vm/freepages read-only?!?
Hi, I'm trying to do some vm tuning for diskless (and therefore swapless) devices. (I'm working on a distro that tftp's packages and runs entirely in RAM) Even on an X terminal with 64MB RAM, badly behaved apps can use lots of ram in the Xserver, and what I'm seeing is a hang. The box is usually still pingable, just unresponsive. I'm using cramfs pretty heavily, and I think what's occuring is that the terminal gets too low on freepages, and since pages used by X can't be swapped out, the box starts thrashing the vm and is unable to get pages to uncompress into. My first thought was echo (bigger numbers) > /proc/sys/vm/freepages - but lo! - it's not writable anymore. I found comments in page_alloc.c indicating it had to be read-only, but it seems it's only a safety precaution. Something along the lines of values too small being 'bad bad'. help? David -- David L. Parsley Network Administrator Roanoke College - 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/
/proc/sys/vm/freepages read-only?!?
Hi, I'm trying to do some vm tuning for diskless (and therefore swapless) devices. (I'm working on a distro that tftp's packages and runs entirely in RAM) Even on an X terminal with 64MB RAM, badly behaved apps can use lots of ram in the Xserver, and what I'm seeing is a hang. The box is usually still pingable, just unresponsive. I'm using cramfs pretty heavily, and I think what's occuring is that the terminal gets too low on freepages, and since pages used by X can't be swapped out, the box starts thrashing the vm and is unable to get pages to uncompress into. My first thought was echo (bigger numbers) /proc/sys/vm/freepages - but lo! - it's not writable anymore. I found comments in page_alloc.c indicating it had to be read-only, but it seems it's only a safety precaution. Something along the lines of values too small being 'bad bad'. help? David -- David L. Parsley Network Administrator Roanoke College - 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?
Alan Cox wrote: > The extreme answer to the 2.4 networking performance is the tux specweb > benchmarks but they dont answer for all cases clearly. However, I think you've hit the nail on the head here; much of tux is just general-purpose network file-blasting. The right hacker could turn it into the fastest web-cache on the planet with the right modules. I believe Ingo already did a basic ftp server based on tux, just to demonstrate this generality. Ingo? Am I crazy or enlightened? regards, David - 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?
snip stuff about someone using linux for a web cache Alan Cox wrote: The extreme answer to the 2.4 networking performance is the tux specweb benchmarks but they dont answer for all cases clearly. However, I think you've hit the nail on the head here; much of tux is just general-purpose network file-blasting. The right hacker could turn it into the fastest web-cache on the planet with the right modules. I believe Ingo already did a basic ftp server based on tux, just to demonstrate this generality. Ingo? Am I crazy or enlightened? regards, David - 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][CFT] per-process namespaces for Linux
Alexander Viro wrote:
> > Evil idea of the day: non-directory (even non-existant) mount points and
> > non-directory mounts. So then "mount --bind /etc/foo /dev/bar" works.
>
> Try it. It _does_ work.
Yeah, mount --bind is cool, I've been using it on one of my projects
today. But - maybe I'm just not thinking creatively enough - what are
the advantages of mount --bind versus just symlinking?
Also, I tried mount --bind fileone filetwo, and it fails if filetwo
doesn't exist. ('mount point filetwo doesn't exist'). Is that supposed
to work? (using mount from latest redhat beta)
BTW, pivot_root is nifty, too. ;-)
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
-
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][CFT] per-process namespaces for Linux
Alexander Viro wrote:
Evil idea of the day: non-directory (even non-existant) mount points and
non-directory mounts. So then "mount --bind /etc/foo /dev/bar" works.
Try it. It _does_ work.
Yeah, mount --bind is cool, I've been using it on one of my projects
today. But - maybe I'm just not thinking creatively enough - what are
the advantages of mount --bind versus just symlinking?
Also, I tried mount --bind fileone filetwo, and it fails if filetwo
doesn't exist. ('mount point filetwo doesn't exist'). Is that supposed
to work? (using mount from latest redhat beta)
BTW, pivot_root is nifty, too. ;-)
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
-
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: Is sendfile all that sexy?
Jakub Jelinek wrote: > > This makes me wonder... > > > > If the kernel only kept a queue of the three smallest unused fd's, and > > when the queue emptied handed out whatever it liked, how many things > > would break? I suspect this would cover a lot of bases... > > First it would break Unix98 and other standards: [snip] Yeah, I reallized it would violate at least POSIX. The discussion was just bandying about ways to avoid an expensive 'open()' without breaking lots of utilities and glibc stuff. This might be something that could be configured for specific server environments, where performance is more imporant than POSIX/Unix98, but you still don't want to completely break the system. Just a thought, brain-damaged as it might be. ;-) regards, David -- David L. Parsley Network Administrator Roanoke College - 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: Is sendfile all that sexy?
Felix von Leitner wrote:
> > close (0);
> > close (1);
> > close (2);
> > open ("/dev/console", O_RDWR);
> > dup ();
> > dup ();
>
> So it's not actually part of POSIX, it's just to get around fixing
> legacy code? ;-)
This makes me wonder...
If the kernel only kept a queue of the three smallest unused fd's, and
when the queue emptied handed out whatever it liked, how many things
would break? I suspect this would cover a lot of bases...
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
-
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: Is sendfile all that sexy?
Felix von Leitner wrote:
close (0);
close (1);
close (2);
open ("/dev/console", O_RDWR);
dup ();
dup ();
So it's not actually part of POSIX, it's just to get around fixing
legacy code? ;-)
This makes me wonder...
If the kernel only kept a queue of the three smallest unused fd's, and
when the queue emptied handed out whatever it liked, how many things
would break? I suspect this would cover a lot of bases...
dons flameproof underwear
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
-
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: Is sendfile all that sexy?
Jakub Jelinek wrote: This makes me wonder... If the kernel only kept a queue of the three smallest unused fd's, and when the queue emptied handed out whatever it liked, how many things would break? I suspect this would cover a lot of bases... First it would break Unix98 and other standards: [snip] Yeah, I reallized it would violate at least POSIX. The discussion was just bandying about ways to avoid an expensive 'open()' without breaking lots of utilities and glibc stuff. This might be something that could be configured for specific server environments, where performance is more imporant than POSIX/Unix98, but you still don't want to completely break the system. Just a thought, brain-damaged as it might be. ;-) regards, David -- David L. Parsley Network Administrator Roanoke College - 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/
[PATCH] one-liner fix for bforget() honoring BH_Protected; was: Re: Patch (repost): cramfs memory corruption fix
Linus Torvalds wrote:
>
> On Sat, 6 Jan 2001, Adam J. Richter wrote:
> >
> > This sounds like a bug that I posted a fix for a long time ago.
> > cramfs calls bforget on the superblock area, destroying that block of
> > the ramdisk, even when the ramdisk does not contain a cramfs file system.
> > Normally, bforget is called on block that really can be trashed,
> > such as blocks release by truncate or unlink.
>
> I'd really prefer just not letting bforget() touch BH_Protected buffers.
> bforget() is also used by other things than unlink/truncate: it's used by
> various partition codes etc, and it's used by the raid logic.
Yup, I backed out Adam's one-liner in favor of the attached one-liner.
Tested on 2.4.0, but should patch cleanly to just about anything. ;-)
BTW Linus - you were of course right on the cramfs wanting 4096
blocksize... but without this fix, that doesn't matter much. ;-)
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
--- linux.linus/fs/buffer.c Wed Jan 3 23:45:26 2001
+++ linux/fs/buffer.c Wed Jan 10 15:49:36 2001
@@ -1145,13 +1145,15 @@
* free list if it can.. We can NOT free the buffer if:
* - there are other users of it
* - it is locked and thus can have active IO
+ * - it is marked BH_Protected
*/
void __bforget(struct buffer_head * buf)
{
/* grab the lru lock here to block bdflush. */
spin_lock(_list_lock);
write_lock(_table_lock);
- if (!atomic_dec_and_test(>b_count) || buffer_locked(buf))
+ if (!atomic_dec_and_test(>b_count) || buffer_locked(buf) ||
+ buffer_protected(buf))
goto in_use;
__hash_unlink(buf);
remove_inode_queue(buf);
[PATCH] one-liner fix for bforget() honoring BH_Protected; was: Re: Patch (repost): cramfs memory corruption fix
Linus Torvalds wrote:
On Sat, 6 Jan 2001, Adam J. Richter wrote:
This sounds like a bug that I posted a fix for a long time ago.
cramfs calls bforget on the superblock area, destroying that block of
the ramdisk, even when the ramdisk does not contain a cramfs file system.
Normally, bforget is called on block that really can be trashed,
such as blocks release by truncate or unlink.
I'd really prefer just not letting bforget() touch BH_Protected buffers.
bforget() is also used by other things than unlink/truncate: it's used by
various partition codes etc, and it's used by the raid logic.
Yup, I backed out Adam's one-liner in favor of the attached one-liner.
Tested on 2.4.0, but should patch cleanly to just about anything. ;-)
BTW Linus - you were of course right on the cramfs wanting 4096
blocksize... but without this fix, that doesn't matter much. ;-)
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
--- linux.linus/fs/buffer.c Wed Jan 3 23:45:26 2001
+++ linux/fs/buffer.c Wed Jan 10 15:49:36 2001
@@ -1145,13 +1145,15 @@
* free list if it can.. We can NOT free the buffer if:
* - there are other users of it
* - it is locked and thus can have active IO
+ * - it is marked BH_Protected
*/
void __bforget(struct buffer_head * buf)
{
/* grab the lru lock here to block bdflush. */
spin_lock(lru_list_lock);
write_lock(hash_table_lock);
- if (!atomic_dec_and_test(buf-b_count) || buffer_locked(buf))
+ if (!atomic_dec_and_test(buf-b_count) || buffer_locked(buf) ||
+ buffer_protected(buf))
goto in_use;
__hash_unlink(buf);
remove_inode_queue(buf);
question on generating a patch
I read the FAQ and SubmittingPatches, but how best to generate a patch that moves a file from on dir to another? diff -urNP makes the patch a lot longer than it seems like it should be... (fortunately it's just a short header file) Is there a better way? regards, David -- David L. Parsley Network Administrator Roanoke College - 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/
question on generating a patch
I read the FAQ and SubmittingPatches, but how best to generate a patch that moves a file from on dir to another? diff -urNP makes the patch a lot longer than it seems like it should be... (fortunately it's just a short header file) Is there a better way? regards, David -- David L. Parsley Network Administrator Roanoke College - 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 (repost): cramfs memory corruption fix
Alan Cox wrote:
> -ac has the rather extended ramfs with resource limits and stuff. That one
> also has rather more extended bugs 8). AFAIK none of those are in the vanilla
> ramfs code
Nifty stuff, too; it's nice for a ramfs mount to show up in 'df' with
useful figures. Shame I can't put anything there. ;-)
2.4.0 ramfs with the one-liner does it's job for me already; what I'd
really love to fool with is _cramfs_. ;-) In case you missed the
beginning of this thread: all my cramfs initrd's fail to mount as
/dev/ram0 with 'wrong magic'; their romfs counterparts work fine. I did
manage to pivot_root into a cramfs root, but it blew up pretty quick
with 'attempt to access beyond end of device', and killed my init
shell. Then there's the wierdness where cramfs compiled in the kernel
corrupts the romfs. Adam's one-liner (bforget -> brelse on superblock)
didn't fix this.
The cramfs docs are contradictory btw; the kernel help says 'doesn't
support hardlinks', and Documentation/filesystems/cramfs.txt says
'Hardlinks are supported, but...'. I made my cramfs with and without
hardlinks (to busybox); but that didn't affect whether it mounted. I
haven't tested whether this fixes the 'access beyond end of device'
problems.
regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
-
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 (repost): cramfs memory corruption fix
Alan Cox wrote: -ac has the rather extended ramfs with resource limits and stuff. That one also has rather more extended bugs 8). AFAIK none of those are in the vanilla ramfs code Nifty stuff, too; it's nice for a ramfs mount to show up in 'df' with useful figures. Shame I can't put anything there. ;-) 2.4.0 ramfs with the one-liner does it's job for me already; what I'd really love to fool with is _cramfs_. ;-) In case you missed the beginning of this thread: all my cramfs initrd's fail to mount as /dev/ram0 with 'wrong magic'; their romfs counterparts work fine. I did manage to pivot_root into a cramfs root, but it blew up pretty quick with 'attempt to access beyond end of device', and killed my init shell. Then there's the wierdness where cramfs compiled in the kernel corrupts the romfs. Adam's one-liner (bforget - brelse on superblock) didn't fix this. The cramfs docs are contradictory btw; the kernel help says 'doesn't support hardlinks', and Documentation/filesystems/cramfs.txt says 'Hardlinks are supported, but...'. I made my cramfs with and without hardlinks (to busybox); but that didn't affect whether it mounted. I haven't tested whether this fixes the 'access beyond end of device' problems. regards, David -- David L. Parsley Network Administrator Roanoke College - 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/
cramfs & ramfs problems in 2.4.0 up to ac3
Hi, Using root=/dev/ram0 and a cramfs initrd gives me 'wrong magic' when it tries to boot. Even more bizarre, if cramfs is compiled in the kernel when I use a romfs root, it says 'wrong magic' then mounts the romfs but can't find init. If I take cramfs out of the kernel, the romfs mounts & init runs fine. I just saw this with ac3. ramfs croaks with 'kernel BUG in filemap.c line 2559' anytime I make a file in ac2 and ac3. Works fine in 2.4.0 vanilla. Should be quite repeatable... BTW, nice work on 2.4 everyone. regards, David -- David L. Parsley Network Administrator Roanoke College - 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/
cramfs ramfs problems in 2.4.0 up to ac3
Hi, Using root=/dev/ram0 and a cramfs initrd gives me 'wrong magic' when it tries to boot. Even more bizarre, if cramfs is compiled in the kernel when I use a romfs root, it says 'wrong magic' then mounts the romfs but can't find init. If I take cramfs out of the kernel, the romfs mounts init runs fine. I just saw this with ac3. ramfs croaks with 'kernel BUG in filemap.c line 2559' anytime I make a file in ac2 and ac3. Works fine in 2.4.0 vanilla. Should be quite repeatable... BTW, nice work on 2.4 everyone. regards, David -- David L. Parsley Network Administrator Roanoke College - 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/
