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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.