public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Andries.Brouwer@cwi.nl
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 21:49:55 +0100	[thread overview]
Message-ID: <20010218214955.C6593@suse.de> (raw)
In-Reply-To: <UTC200102181934.UAA168081.aeb@vlet.cwi.nl>
In-Reply-To: <UTC200102181934.UAA168081.aeb@vlet.cwi.nl>; from Andries.Brouwer@cwi.nl on Sun, Feb 18, 2001 at 08:34:03PM +0100

On Sun, Feb 18 2001, Andries.Brouwer@cwi.nl wrote:
>     > A value of hardsect_size[] means: this is the smallest size
>     > the hardware can work with. It is therefore a serious mistake
>     > just to come with "a good guess". This value is used only
> 
>     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.
Did you verify that changing block size works? Just curious.

> that hardware exists that is unable to, but it is a bad idea
> to refuse to mount filesystems just because of some "good guess"
> that was not so good at all.

By far most media used will be 2kB based, so it is a good guess. Of course
we change it if we switch the block size.

>     So put 0 and sure anyone can submit I/O on the size that they want.
>     Now the driver has to support padding reads, or gathering data to do
>     a complete block write. This is silly. Sr should support 512b transfers
>     just fine, but only because I added the necessary _hacks_ to support
>     it. sd doesn't right now for instance.
> 
> Please calm down. Removing this sr_hardsizes nonsense

I'm perfectly calm.

> 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.

-- 
Jens Axboe


  reply	other threads:[~2001-02-18 20:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-18 19:34 [PROBLEM] 2.4.1 can't mount ext2 CD-ROM Andries.Brouwer
2001-02-18 20:49 ` Jens Axboe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-02-18 21:11 Andries.Brouwer
2001-02-19  1:43 ` 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=20010218214955.C6593@suse.de \
    --to=axboe@suse.de \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --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