On Wed, 10 Jan 2001, David L. Parsley wrote:
>
> 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
>From: "David L. Parsley" <[EMAIL PROTECTED]>
>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
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
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.
From: "David L. Parsley" [EMAIL PROTECTED]
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
On Wed, 10 Jan 2001, David L. Parsley wrote:
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,
On Sun, 7 Jan 2001, David L. Parsley wrote:
>
> 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
Hi Alan,
On Mon, 8 Jan 2001, Alan Cox wrote:
> I have been thinking about this. I think we should merge the size
> limiting code with the example clean ramfs code. Having spent a
> while debugging the LFS checks and some other funnies I realised one
> problem with the ramfs in 2.4.0 as an
Hi Christoph,
On Mon, 8 Jan 2001, Christoph Hellwig wrote:
> I had a prototype tmpfs in -test10 (ro so) times. It based on ramfs
> for all the metadata stuff and used the (old) shmfs code for
> swap-backed data. The only real problem the code had, was that it
> needed a ->allocpage
> On Sun, 7 Jan 2001, Linus Torvalds wrote:
> > I wonder what to do about this - the limits are obviously useful, as
> > would the "use swap-space as a backing store" thing be. At the same
> > time I'd really hate to lose the lean-mean-clean ramfs.
>
> Let me repeat on this issue: shmem.c has
[EMAIL PROTECTED] said:
> While the topic is raised..., I've hacked up cramfs for linear
> addressing to kill the "double buffering" effiect. However as David
> mentions the block device support thing is an issue here. What is a
> reasonable way to allow a cramfs partition to access the
In article <[EMAIL PROTECTED]> you wrote:
> Hi Linus,
>
> On Sun, 7 Jan 2001, Linus Torvalds wrote:
>> I wonder what to do about this - the limits are obviously useful, as
>> would the "use swap-space as a backing store" thing be. At the same
>> time I'd really hate to lose the lean-mean-clean
On Monday 08 January 2001 13:11, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > Also, if you care about memory usage, you're likely to be much better
> > off using ramfs rather than something like "ext2 on ramdisk". You
> > won't get the double buffering.
>
> That'll be even more useful
Hi Linus,
On Sun, 7 Jan 2001, Linus Torvalds wrote:
> I wonder what to do about this - the limits are obviously useful, as
> would the "use swap-space as a backing store" thing be. At the same
> time I'd really hate to lose the lean-mean-clean ramfs.
Let me repeat on this issue: shmem.c has
[EMAIL PROTECTED] said:
> Also, if you care about memory usage, you're likely to be much better
> off using ramfs rather than something like "ext2 on ramdisk". You
> won't get the double buffering.
That'll be even more useful once we can completely configure out all
support for block devices
[EMAIL PROTECTED] said:
Also, if you care about memory usage, you're likely to be much better
off using ramfs rather than something like "ext2 on ramdisk". You
won't get the double buffering.
That'll be even more useful once we can completely configure out all
support for block devices
Hi Linus,
On Sun, 7 Jan 2001, Linus Torvalds wrote:
I wonder what to do about this - the limits are obviously useful, as
would the "use swap-space as a backing store" thing be. At the same
time I'd really hate to lose the lean-mean-clean ramfs.
Let me repeat on this issue: shmem.c has
On Monday 08 January 2001 13:11, David Woodhouse wrote:
[EMAIL PROTECTED] said:
Also, if you care about memory usage, you're likely to be much better
off using ramfs rather than something like "ext2 on ramdisk". You
won't get the double buffering.
That'll be even more useful once we can
In article [EMAIL PROTECTED] you wrote:
Hi Linus,
On Sun, 7 Jan 2001, Linus Torvalds wrote:
I wonder what to do about this - the limits are obviously useful, as
would the "use swap-space as a backing store" thing be. At the same
time I'd really hate to lose the lean-mean-clean ramfs.
Let
[EMAIL PROTECTED] said:
While the topic is raised..., I've hacked up cramfs for linear
addressing to kill the "double buffering" effiect. However as David
mentions the block device support thing is an issue here. What is a
reasonable way to allow a cramfs partition to access the device
On Sun, 7 Jan 2001, Linus Torvalds wrote:
I wonder what to do about this - the limits are obviously useful, as
would the "use swap-space as a backing store" thing be. At the same
time I'd really hate to lose the lean-mean-clean ramfs.
Let me repeat on this issue: shmem.c has everything
Hi Christoph,
On Mon, 8 Jan 2001, Christoph Hellwig wrote:
I had a prototype tmpfs in -test10 (ro so) times. It based on ramfs
for all the metadata stuff and used the (old) shmfs code for
swap-backed data. The only real problem the code had, was that it
needed a -allocpage address_space
Hi Alan,
On Mon, 8 Jan 2001, Alan Cox wrote:
I have been thinking about this. I think we should merge the size
limiting code with the example clean ramfs code. Having spent a
while debugging the LFS checks and some other funnies I realised one
problem with the ramfs in 2.4.0 as an example.
On Sun, 7 Jan 2001, David L. Parsley wrote:
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
Rik van Riel <[EMAIL PROTECTED]> writes:
> On Sun, 7 Jan 2001, Linus Torvalds wrote:
> > On Sun, 7 Jan 2001, 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
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
> Sounds like a job for ... ... tmpfs!!
>
> (and yes, I share your opinion that ramfs is nice _because_
> it's an easy example for filesystem code teaching)
The resource tracking ramfs isnt that much uglier to be honest. One that went
off using backing store would be, but ramfs with limits
On Sun, 7 Jan 2001, Linus Torvalds wrote:
> On Sun, 7 Jan 2001, 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
> This is actually where I agree with
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
On Sun, 7 Jan 2001, Alan Cox wrote:
> > > I'll take a look at the ramfs one. I may have broken something else when fixing
> > > everything else with ramfs (like unlink) crashing
> >
> > Ehh.. Plain 2.4.0 ramfs is fine, assuming you add a "UnlockPage()" to
> > ramfs_writepage(). So what do you
> > I'll take a look at the ramfs one. I may have broken something else when fixing
> > everything else with ramfs (like unlink) crashing
>
> Ehh.. Plain 2.4.0 ramfs is fine, assuming you add a "UnlockPage()" to
> ramfs_writepage(). So what do you mean by "fixing everything else"?
-ac has the
On Sun, 7 Jan 2001, Alan Cox wrote:
> > >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...
>
> I'll take a look at the ramfs one. I may have broken something else when fixing
>
> >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...
I'll take a look at the ramfs one. I may have broken something else when fixing
everything else with ramfs (like unlink) crashing
>
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...
I'll take a look at the ramfs one. I may have broken something else when fixing
everything else with ramfs (like unlink) crashing
On Sun, 7 Jan 2001, Alan Cox wrote:
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...
I'll take a look at the ramfs one. I may have broken something else when fixing
everything else
I'll take a look at the ramfs one. I may have broken something else when fixing
everything else with ramfs (like unlink) crashing
Ehh.. Plain 2.4.0 ramfs is fine, assuming you add a "UnlockPage()" to
ramfs_writepage(). So what do you mean by "fixing everything else"?
-ac has the rather
On Sun, 7 Jan 2001, Alan Cox wrote:
I'll take a look at the ramfs one. I may have broken something else when fixing
everything else with ramfs (like unlink) crashing
Ehh.. Plain 2.4.0 ramfs is fine, assuming you add a "UnlockPage()" to
ramfs_writepage(). So what do you mean by
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
On Sun, 7 Jan 2001, Linus Torvalds wrote:
On Sun, 7 Jan 2001, 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
This is actually where I agree with whoever
Sounds like a job for ... drum roll ... tmpfs!!
(and yes, I share your opinion that ramfs is nice _because_
it's an easy example for filesystem code teaching)
The resource tracking ramfs isnt that much uglier to be honest. One that went
off using backing store would be, but ramfs with
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
Rik van Riel [EMAIL PROTECTED] writes:
On Sun, 7 Jan 2001, Linus Torvalds wrote:
On Sun, 7 Jan 2001, 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
>From: "David L. Parsley" <[EMAIL PROTECTED]>
>
>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
From: "David L. Parsley" [EMAIL PROTECTED]
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
44 matches
Mail list logo
