From: Jan Kara <jack@suse.cz>
To: Steve Magnani <steve.magnani@digidescorp.com>
Cc: "Jan Kara" <jack@suse.cz>, "Pali Rohár" <pali.rohar@gmail.com>,
linux-fsdevel@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] udf: 2.01 interoperability issues with Windows 10
Date: Tue, 9 Jul 2019 21:55:35 +0200 [thread overview]
Message-ID: <20190709195535.GA509@quack2.suse.cz> (raw)
In-Reply-To: <96e1ea00-ac12-015d-5c54-80a83f08b898@digidescorp.com>
Hi!
On Tue 09-07-19 13:27:58, Steve Magnani wrote:
> Recently I have been exploring Advanced Format (4K sector size)
> and high capacity aspects of UDF 2.01 support in Linux and
> Windows 10. I thought it might be helpful to summarize my findings.
>
> The good news is that I did not see any bugs in the Linux
> ecosystem (kernel driver + mkudffs).
>
> The not-so-good news is that Windows has some issues that affect
> interoperability. One of my goals in posting this is to open a
> discussion on whether changes should be made in the Linux UDF
> ecosystem to accommodate these quirks.
>
> My test setup includes the following software components:
>
> * mkudffs 1.3 and 2.0
> * kernel 4.15.0-43 and 4.15.0-52
> * Windows 10 1803 17134.829
> * chkdsk 10.0.17134.1
> * udfs.sys 10.0.17134.648
>
>
> ISSUE 1: Inability of the Linux UDF driver to mount 4K-sector
> media formatted by Windows.
>
> This is because the Windows ecosystem mishandles the ECMA-167
> corner case that requires Volume Recognition Sequence components
> to be placed at 4K intervals on 4K-sector media, instead of the
> 2K intervals required with smaller sectors. The Linux UDF driver
> emits the following when presented with Windows-formatted media:
>
> UDF-fs: warning (device sdc1): udf_load_vrs: No VRS found
> UDF-fs: Scanning with blocksize 4096 failed
>
> A hex dump of the VRS written by the Windows 10 'format' utility
> yields this:
>
> 0000: 00 42 45 41 30 31 01 00 00 00 00 00 00 00 00 00 .BEA01..........
> 0800: 00 4e 53 52 30 33 01 00 00 00 00 00 00 00 00 00 .NSR03..........
> 1000: 00 54 45 41 30 31 01 00 00 00 00 00 00 00 00 00 .TEA01..........
>
> We may want to consider tweaking the kernel UDF driver to
> tolerate this quirk; if so a question is whether that should be
> done automatically, only in response to a mount option or
> module parameter, or only with some subsequent confirmation
> that the medium was formatted by Windows.
Yeah, I think we could do that although it will be a bit painful. I would
do it by default if we found BEA descriptor but not NSR descriptor. We do
already have handling for various quirks of other udf creators so this is
nothing new... I think Palo replied about the rest of the issues you've
found.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2019-07-09 19:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-09 18:27 [RFC] udf: 2.01 interoperability issues with Windows 10 Steve Magnani
2019-07-09 18:56 ` Pali Rohár
2019-07-09 20:14 ` Steve Magnani
2019-07-09 21:04 ` Pali Rohár
2019-07-10 13:24 ` Steve Magnani
2019-07-10 13:50 ` Pali Rohár
2019-07-09 19:55 ` Jan Kara [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=20190709195535.GA509@quack2.suse.cz \
--to=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pali.rohar@gmail.com \
--cc=steve.magnani@digidescorp.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;
as well as URLs for NNTP newsgroup(s).