lkml.org 
[lkml]   [1999]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RAMDISK Bug - 2.0.36 kernel (again)

Stephen

Thanks for the reply. I thought the buffering was done at the block level
and that the ramdisk code worked by basically setting the BH_Protected
flag of the provided buffer on a write request (to prevent it ever get
freed up) and if it should get a read request simply return zeroes,
because there is no real block device to read. So even if files get
deleted, that still involves writes to the block device and surely
freeing the buffer might me you lose vital data from the filesystem
structure.

My simplistic understanding of this would lead me to believe that buffer
management code might check the BH_Protected flag, but never clear it.

Regarding the swap issue, I am sure I tried this on a machine with a hard
disk, but no swap. It was OK.

Any other comments from you or anyone else would be appreciated, I would
much rather fix the problem than work around it.

Bill Melotti
Cognito Ltd UK

On Wed, 27 Jan 1999, Stephen C. Tweedie wrote:

> Hi,
>
> On Tue, 26 Jan 1999 17:23:27 +0000 (GMT), Bill Melotti
> <billy@cognito.co.uk> said:
>
> > It is as if the RAMDISK code as not marked the buffers it uses as
> > unavailable for app code. I looked through the code and see it sets the
> > BH_Protected flag in the file buffer structs. However I also see that
> > there are 2 or 3 places (fs/buffers.c and somewhere in ext2 hierarchy)
> > where these can be cleared.
>
> Ramdisk does reserve its buffers, at least until you start deleting
> files on the ramdisk (which is the only place we would clear the
> protected flag).
>
> > Can anyone offer any help/comments/suggestions ?
>
> Adding swap is the only recommended the way to avoid painful VM deaths
> like this, I'm afraid. Otherwise, just make the ramdisk as small as
> possible: using mke2fs options to reduce the number of inodes on the
> ramdisk, or even using the minix fs, might help.
>
> --Stephen
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> 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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.059 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site