public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Malcolm H. Teas" <mhteas@btech.com>
To: Alan Cox <alan@redhat.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Ramdisk ioctl bug fix, kernel 2.4.14
Date: Tue, 13 Nov 2001 08:04:16 -0600	[thread overview]
Message-ID: <3BF12860.1050302@btech.com> (raw)
In-Reply-To: <200111130916.fAD9Gvi32288@devserv.devel.redhat.com>

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


  reply	other threads:[~2001-11-13 14:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-13  2:39 [PATCH] Ramdisk ioctl bug fix, kernel 2.4.14 Malcolm H. Teas
2001-11-13  9:16 ` Alan Cox
2001-11-13 14:04   ` Malcolm H. Teas [this message]
2001-11-13 16:56     ` Alan Cox
2001-11-13 20:15       ` Malcolm H. Teas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BF12860.1050302@btech.com \
    --to=mhteas@btech.com \
    --cc=alan@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox