From: Andries.Brouwer@cwi.nl
To: Andries.Brouwer@cwi.nl, axboe@suse.de
Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org,
zzed@cyberdude.com
Subject: Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
Date: Sun, 18 Feb 2001 22:11:36 +0100 (MET) [thread overview]
Message-ID: <UTC200102182111.WAA170825.aeb@vlet.cwi.nl> (raw)
> You are defeating the entire purpose of having a hardware sector
> size independently from the software block size. And 2kB is a
> valid guess, apart from the drives that do 512 byte transfers too
> 2kB is really the smallest transfer we can do.
>
> : And 2kB is a valid guess
>
> Strange. The twelve or so CD readers I have here are all
> able to read 512-byte sectors. I am quite willing to believe
I think most Plextor and Yamaha do, but it's not guaranteed to
be supported. And it definitely won't for ATAPI with ide-scsi.
Strange. I just used ATAPI with ide-scsi as test. It works.
Did you verify that changing block size works? Just curious.
Maybe you misunderstand.
In reality no blocksize is changed.
Setting hardsect_size to 2048 means: this hardware is unable
to use smaller blocks, give an error to whoever asks for
something smaller.
Not setting hardsect_size at all means: I have no idea what this
hardware can do. Now it is up to the user. If the user tries
something the hardware cannot do, she will get EIO.
Limiting the user in advance is a bad idea.
But yes, I found an old CDROM with a blocksize of 1024,
which was rejected by 2.4.1 and accepted by 2.4.1 after
removing al mention of sr_hardsizes from sr.c.
> is a good idea today. No padding reads involved.
> If you disagree, please go slowly and state very explicitly
> why you think I should be unable to mount ext2 filesystems with
> a block size smaller than 2048 on my SCSI CD drive.
I don't think you should be unable to, of course we would want to
support 1kB ext2 and other file systems that want to change the block
size. We are just disagreeing on how to do it. I don't think counting
on being able to change the block size of a device at will always
be reliable.
It is not clear to me what you mean by "changing the block size".
What problems do you see?
Don't forget that 2.2 does not have sr_hardsizes, so all problems
you see should be present in 2.2.
Andries
next reply other threads:[~2001-02-18 21:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-18 21:11 Andries.Brouwer [this message]
2001-02-19 1:43 ` [PROBLEM] 2.4.1 can't mount ext2 CD-ROM Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2001-02-18 19:34 Andries.Brouwer
2001-02-18 20:49 ` Jens Axboe
2001-02-18 17:49 Andries.Brouwer
2001-02-18 19:16 ` Jens Axboe
2001-02-19 1:40 ` Alan Cox
2001-02-19 1:47 ` Jens Axboe
2001-02-19 2:02 ` Alan Cox
2001-02-18 14:26 Jon Forsberg
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=UTC200102182111.WAA170825.aeb@vlet.cwi.nl \
--to=andries.brouwer@cwi.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=zzed@cyberdude.com \
/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