The patch below makes the ramdisk return the actual size that is currently
allocated instead of returning the max size we can possibly allocate. Affects
system calls ioctl(filedes, BLKGETSIZE) and ioctl(filedes, BLKGETSIZE64) for
ramdisk devices.
Malcolm Teas
[email protected]
http://www.btech.com
Austin, TX USA
--- linux-2.4.14/drivers/block/rd.c Thu Oct 25 15:58:35 2001
+++ linux/drivers/block/rd.c Mon Nov 12 20:15:16 2001
@@ -40,6 +40,9 @@
*
* Make block size and block size shift for RAM disks a global macro
* and set blk_size for -ENOSPC, Werner Fink <[email protected]>, Apr '99
+ *
+ * Make BLKGETSIZE and BLKGETSIZE64 return the actual allocated size, not
+ * the max possible allocated size - Malcolm Teas Nov 2001
*/
#include <linux/config.h>
@@ -349,6 +352,7 @@
{
int error = -EINVAL;
unsigned int minor;
+
unsigned long size;
if (!inode || !inode->i_rdev)
goto out;
@@ -373,10 +377,12 @@
case BLKGETSIZE: /* Return device size */
if (!arg)
break;
-
error = put_user(rd_kbsize[minor] << 1, (unsigned long *) arg);
+
size = (rd_bdev[minor]->bd_inode->i_mapping->nrpages * PAGE_SIZE) >> 9;
+
error = put_user(size, (unsigned long *) arg);
break;
case BLKGETSIZE64:
-
error = put_user((u64)rd_kbsize[minor]<<10, (u64*)arg);
+
size = rd_bdev[minor]->bd_inode->i_mapping->nrpages;
+
error = put_user((u64) (size * PAGE_SIZE), (u64*)arg);
break;
case BLKROSET:
case BLKROGET:
> The patch below makes the ramdisk return the actual size that is currently
> allocated instead of returning the max size we can possibly allocate. Affects
> system calls ioctl(filedes, BLKGETSIZE) and ioctl(filedes, BLKGETSIZE64) for
> ramdisk devices.
That seems to be the opposite of what its always done, and also of what
disk devices do.
Alan,
With respect, I'd make the argument that if one makes a ram disk 1024 blocks in
size, and the max size is set to the default of 4096, the ioctl should return
the actual current size of 1024. To do otherwise would lead people and userland
tools to think the ram disk is larger than it actually is.
From this point of view, the fact that it's done this in the past is a bug.
I've been typically using the commands:
dd if=/dev/zero of=/dev/ram1 bs=1k count=1720 (or whatever size is appropriate)
mkfs -t ext2 /dev/ram1
In this case, the ioctl reports 1720 blocks for the /dev/ram1 and zero for the
other ram disks not yet used. This is more useful than having all ram disks -
used or not - always report 4096. It's also a good double check on the actual
configuration one's using for their ram disks.
Most disk devices can't change their size with a few commands as a ram disk can
as it's a physical constant. Ram disks are virtual so their size is whatever
the user specifies, with a kernel configured upper limit. I argue that the size
is the allocated amount, not the upper limit.
Thanks,
-Malcolm
Alan Cox wrote:
>>The patch below makes the ramdisk return the actual size that is currently
>>allocated instead of returning the max size we can possibly allocate. Affects
>>system calls ioctl(filedes, BLKGETSIZE) and ioctl(filedes, BLKGETSIZE64) for
>>ramdisk devices.
>>
>
> That seems to be the opposite of what its always done, and also of what
> disk devices do.
>
>
>
--
Malcolm H. Teas, http://www.btech.com/
Blaze Technology, Inc. Austin TX
Remember 9/11/2001
> Most disk devices can't change their size with a few commands as a ram disk can
> as it's a physical constant. Ram disks are virtual so their size is whatever
> the user specifies, with a kernel configured upper limit. I argue that the size
> is the allocated amount, not the upper limit.
I think your problem is that you are querying the disk to ask it the file
system size ? If so you asked the wrong code
Alan Cox wrote:
>>Most disk devices can't change their size with a few commands as a ram disk can
>>as it's a physical constant. Ram disks are virtual so their size is whatever
>>the user specifies, with a kernel configured upper limit. I argue that the size
>>is the allocated amount, not the upper limit.
>>
>
> I think your problem is that you are querying the disk to ask it the file
> system size ? If so you asked the wrong code
I take your point. The file system knows its right size. However, it would
still be useful to be able to tell what the ram disk allocated size actually is.
Currently there's no good mechanism I know of that returns the actual
allocated size.
I'm using ram disks as a way of building a single floppy linux I'm working on (a
variation on LRP and Tom's Root Boot). Some of the time in this process I have
ram disk(s) without filesystems to query for the size. It's also possible to
build a filesystem that's smaller than the allocated size.
Mypatch doesn't affect userland tools like "du" and "df" since they query the
filesystem for the size. It does fix lowel-level tools that look at the ramdisk
and not the filesystem.
Having the ramdisk report the max possible size and not the allocated size is
akin to having a physical hard disk report the theoretical max that could be
achieved using current technology, not the actual blocks the device is built to
hold.
-Malcolm