Date:   Wed, 10 Jul 2019 15:50:42 +0200
From:   Pali Rohár <pali.rohar@...il.com>
To:     Steve Magnani <steve.magnani@...idescorp.com>
Cc:     Jan Kara <jack@...e.cz>,
        Vojtěch Vladyka <vojtech.vladyka@...yco.cz>,
        linux-fsdevel@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] udf: 2.01 interoperability issues with Windows 10

On Wednesday 10 July 2019 08:24:09 Steve Magnani wrote:
> 
> On 7/9/19 4:04 PM, Pali Rohár wrote:
> > On Tuesday 09 July 2019 15:14:38 Steve Magnani wrote:
> > > On 7/9/19 1:56 PM, Pali Rohár wrote:
> > > > Can grub2 recognize such disks?
> > > I'm not sure what you're asking here. The physical interface to this drive is USB,
> > It is USB mass storage device? If yes, then grub2 should be able to
> > normally use. Read its content, etc... You can use "ls" grub command to
> > list content of disk with supported filesystem.
> 
> Yes, Mass Storage Bulk-Only Transport.
> 
> > 
> > > and it's not designed for general-purpose storage (or booting). That said, if you
> > > have some grub2 commands you want me to run against this drive/partition let me know.
> > There is also some way for using grub's fs implementation to read disk
> > images. It is primary used by grub's automated tests. I do not know
> > right now how to use, I need to look grub documentation. But I have
> > already used it during implementation of UDF UUID in grub.
> 
> Grub is not recognizing my USB drive, i.e. 'ls' does not show usb0 as an option.
> I tried 'insmod usb' but that made no difference. Maybe grub does not support my
> USB 3.0 host controller, I will retry on a USB2 port when I have a chance.

In some cases, BIOS/UEFI firmware supports USB mass storage devices and
then grub see them... So it depends on how grub access to disk. Pre-boot
environment is always fragile...

> > > > Also can you check if libparted from git master branch can recognize
> > > > such disk? In following commit I added support for recognizing UDF
> > > > filesystem in libparted, it is only in git master branch, not released:
> > > > 
> > > > http://git.savannah.gnu.org/cgit/parted.git/commit/?id=8740cfcff3ea839dd6dc8650dec0a466e9870625
> > > Build failed:
> > >    In file included from pt-tools.c:114:0:
> > >    pt-tools.c: In function 'pt_limit_lookup':
> > >    pt-limit.gperf:78:1: error: function might be candidate for attribute 'pure' [-Werror=suggest-attribute=pure]
> > > 
> > > If you send me some other SHA to try I can attempt a rebuild.
> > Try to use top of master branch. That mentioned commit is already in git
> > master.
> > 
> > And if it still produce that error, compile without -Werror flag (or add
> > -Wno-error).
> 
> I had to configure with CFLAGS=-Wno-error.
> 
> It does not recognize Windows-formatted 4K-sector media:
>   Disk /dev/sdb: 17.6TB
>   Sector size (logical/physical): 4096B/4096B
>   Partition Table: msdos
>   Disk Flags:
> 
>   Number  Start   End     Size    Type     File system  Flags
>    1      1049kB  17.6TB  17.6TB  primary
> 

Ok, so it means that GUI/TUI tools based on libparted would have
problems with these disks too.

So ISSUE 1 is big problem for Linux.

> It does recognize mkudffs-formatted media.

That is expected.

> > 
> > > > ISSUE 2: Inability of Windows chkdsk to analyze 4K-sector media
> > > >            formatted by mkudffs.
> > > > This is really bad :-(
> > > > 
> > > > > It would be possible to work around this by tweaking mkudffs to
> > > > > insert dummy BOOT2 components in between the BEA/NSR/TEA:
> > > > > 
> > > > >     0000: 00 42 45 41 30 31 01 00 00 00 00 00 00 00 00 00  .BEA01..........
> > > > >     0800: 00 42 4f 4f 54 32 01 00 00 00 00 00 00 00 00 00  .BOOT2..........
> > > > >     1000: 00 4e 53 52 30 33 01 00 00 00 00 00 00 00 00 00  .NSR03..........
> > > > >     1800: 00 42 4f 4f 54 32 01 00 00 00 00 00 00 00 00 00  .BOOT2..........
> > > > >     2000: 00 54 45 41 30 31 01 00 00 00 00 00 00 00 00 00  .TEA01..........
> > > > > 
> > > > > That would introduce a slight ECMA-167 nonconformity, but Linux
> > > > > does not object and Windows actually performs better. I would
> > > > > have to tweak udffsck though since I believe this could confuse
> > > > > its automatic detection of medium block size.
> > > > I would like to avoid this hack. If chkdsk is unable to detect such
> > > > filesystem, it is really a good idea to let it do try doing filesystem
> > > > checks and recovery? You are saying that udfs.sys can recognize such
> > > > disk and mount it. I think this should be enough.
> > > Fair enough, but it's also reasonable to assume the bugginess is
> > > limited to the VRS corner case. AFAIK that's the only place in ECMA-167
> > > where there is a difference in layout specific to 4K sectors.
> > > With the BOOT2 band-aid chkdsk is able to analyze filesystems on 4Kn media.
> > Main problem with this hack is that it breaks detection of valid UDF
> > filesystems which use VRS for block size detection. I do not know which
> > implementation may use VRS for block size detection, but I do not see
> > anything wrong in this approach.
> 
> I went through this with udffsck. The VRS is not very helpful in
> determining block size because the only time the block size can be
> determined conclusively is when the interval between VRS components
> is > 2048 bytes. With an interval of 2048 bytes, the only conclusion
> that can be drawn is that blocks are no larger than 2048 bytes.

Yes, I know. But for >2048 block sizes it can be used and is allowed by
specification.

> > > I use chkdsk frequently to double-check UDF generation firmware
> > Vojtěch wrote in his thesis that MS's chkdsk sometimes put UDF
> > filesystem into more broken state as before.
> 
> Yes, I have personally experienced this. I don't have chkdsk do
> repairs any more. In my case the problem may be that chkdsk
> poorly handles the cascading corruption that resulted from this:
> 
>     https://lkml.org/lkml/2019/2/8/740
> 
> > > I am writing, and also udffsck work-in-progress.
> > Have you used some Vojtěch's parts? Or are you writing it from scratch?
> > 
> A udffsck discussion should probably continue in another thread.
> Here let me just say that I have been enhancing Vojtěch's code,
> in this fork:
> 
>   https://github.com/smagnani/udftools
> 
> ...as time permits. Since winter ended the time I have available
> for this has plummeted, so progress is very slow. But this recent
> kernel driver patch grew out of work to make sure that udffsck
> handles the UDF "file tail" properly:
> 
>   https://lkml.org/lkml/2019/6/4/551
>   https://lkml.org/lkml/2019/6/30/181

Great, thank you for update.

-- 
Pali Rohár
pali.rohar@...il.com

Powered by blists - more mailing lists