From: Nathan Scott <nathans@sgi.com>
To: Gyorgy Szekely <hoditohod@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: ramdisk driver strange behaviour
Date: Tue, 18 Apr 2006 08:29:31 +1000 [thread overview]
Message-ID: <20060418082931.A1478752@wobbly.melbourne.sgi.com> (raw)
In-Reply-To: <940be6070604140659q31c45599wf729a47ef25103ee@mail.gmail.com>; from hoditohod@gmail.com on Fri, Apr 14, 2006 at 03:59:07PM +0200
On Fri, Apr 14, 2006 at 03:59:07PM +0200, Gyorgy Szekely wrote:
> hi,
> i'm trying to use a ramdisk driver (block/rd.c) and experienced some
> very strnage behaviour. In brief:
> If I set ramdisk_blocksize=512 on the kernel command line, the driver
> operates oddly. I execute the following commands in a shell:
>
> mkfs.ext2 /dev/ram0 ~runs fine, no errors
> mount /dev/ram0 /mnt/disk ~doesn't mount the filesystem, can't find
> it on device
> mkfs.ext2 /dev/ram0 ~runs fine, same as above
> mount /dev/ram0 /mnt/disk ~mounts fine
>
> I have to make exactly this command sequence, to make the fs usable,
> eg: mkfs.ext2 twice without trying to mount doesn't work. Once the
> mount succeeds everything works fine, i can read/write files,
> unmount/remount everything as expected.
> I copied the ramdisk contents with dd into a file, and after the first
> pass it's all zeros nothing else. Like the first mkfs didn't do
> anything.
>
> If I remove the ramdisk_blocksize option from the kernel command line
> (defaults to 1024) then all is ok.
I wonder if this is a strange artifact of the supported blocksizes
for the filesystem you're using...
mkfs.ext2 ...
-b block-size
Specify the size of blocks in bytes. Valid block size
vales are 1024, 2048 and 4096 bytes per block. ...
During mount the filesystem will tell the driver what its minimum
block size is, and the driver is meant to validate that, and return
an error if its too small. Whats probably happening in your case
is a failure to handle the too-small case correctly... oh, hmm, yes,
look at the callers of set_blocksize -- in ext3 its return value is
not being checked afaict, and in ext2 I'm not sure where this setup
is done (doesn't seem to be a set_blocksize call there at all - hmm).
You might try XFS too as a data point - XFS will permit a 512 byte
filesystem blocksize - so try mkfs.xfs -bsize=512 /dev/ram0 and see
if that mounts OK first go... that'd backup the above theory if it
does.
cheers.
--
Nathan
prev parent reply other threads:[~2006-04-17 22:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-14 13:59 Gyorgy Szekely
2006-04-14 21:59 ` Jan Engelhardt
2006-04-17 22:29 ` Nathan Scott [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=20060418082931.A1478752@wobbly.melbourne.sgi.com \
--to=nathans@sgi.com \
--cc=hoditohod@gmail.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
all inboxes | Powered by JetHome®