Linux filesystem development
 help / color / mirror / Atom feed
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: hengyul@cs.unc.edu
Cc: jack@suse.cz,brauner@kernel.org,matthias.goergens@gmail.com,linux-fsdevel@vger.kernel.org,linux-kernel@vger.kernel.org
Subject: Re: [PATCH] isofs: Fix handling of directories with small logical blocks
Date: Sun, 11 Oct 2026 22:29:07 +0200	[thread overview]
Message-ID: <13464510581423749223@scdbackup.webframe.org> (raw)
In-Reply-To: <20261010175649.700233-1-hengyul@cs.unc.edu>

Hi,

Hengyu Liang wrote:
>     mount -t iso9660 -o loop,ro lbs1024.iso /mnt

Do i get it right that lbs1024.iso contains in the Primary Volume
Descriptor at BP 129 to 132 "Logical Block Size" the value 1024
instead of 2048 ?
(Where could i get such an ISO image ? And how was it created ?)

If so:
I agree with Hengyu Liang's assessment of ECMA-119 in regard to
Logical Sector (device-related unit inspired by CD sectors) and
Logical Block (filesystem addressing unit).
Assuming that my understanding of the isofs code is correct, i am
astonished and impressed to see in isofs support for
Logical Block < Logical Sector.


But i see a possible exotic consistency problem:

The mount option block={512|1024|2048} may set the address unit for
reading the volume descriptors in isofs_fill_super():
         opt->blocksize = sb_min_blocksize(s, opt->blocksize);
This means that if it gets through, it is the assumed Logical Sector
size.
Later the block size unit gets overridden by the logical block size
which was read from the chosen volume descriptor:
         if (!sb_set_blocksize(s, orig_zonesize))

The problem would be that during the check for allowed crossing of
logical blocks the Logical Sector size is hardcoded as ISOFS_BLOCK_SIZE
i.e. 2048.
So if the user is allowed to set an initial Sector size, shouldn't this
be used for the check in this patch, too ?

On the other hand, the default of opt->blocksize is 1024, which
obviously does not get into effect, even with 512-byte-per-block
USB sticks.
So can mount option block={512|1024|2048} still have an effect at all ?


Have a nice day :)

Thomas


  reply	other threads:[~2026-10-11 20:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-10 17:56 [PATCH] isofs: Fix handling of directories with small logical blocks Hengyu Liang
2026-10-11 20:29 ` Thomas Schmitt [this message]
2026-10-12  2:10   ` Hengyu Liang
2026-10-12 10:07     ` Thomas Schmitt

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=13464510581423749223@scdbackup.webframe.org \
    --to=scdbackup@gmx.net \
    --cc=brauner@kernel.org \
    --cc=hengyul@cs.unc.edu \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias.goergens@gmail.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