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 14:15:27 -0600 [thread overview]
Message-ID: <3BF17F5F.1090704@btech.com> (raw)
In-Reply-To: <200111131656.fADGuWn06695@devserv.devel.redhat.com>
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
prev parent reply other threads:[~2001-11-13 20:16 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
2001-11-13 16:56 ` Alan Cox
2001-11-13 20:15 ` Malcolm H. Teas [this message]
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=3BF17F5F.1090704@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