>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 whe
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
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 rom
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
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_spac
> 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 eve
[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 dev
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 ram
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 onc
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 ever
[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
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 simp
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 anythi
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 ra
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
> ever
> >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
>
20 matches
Mail list logo
