Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <valdis.kletnieks@vt.edu>
To:     Sasha Levin <sashal@kernel.org>
Cc:     Pali =?iso-8859-1?Q?Roh=E1r?= <pali.rohar@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        devel@driverdev.osuosl.org, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Sasha Levin <alexander.levin@microsoft.com>,
        Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to staging
In-Reply-To: <20200213211847.GA1734@sasha-vm>
References: <20190829205631.uhz6jdboneej3j3c@pali> <184209.1567120696@turing-police> <20190829233506.GT5281@sasha-vm> <20190830075647.wvhrx4asnkrfkkwk@pali> <20191016140353.4hrncxa5wkx47oau@pali> <20191016143113.GS31224@sasha-vm> <20191016160349.pwghlg566hh2o7id@pali> <20191016203317.GU31224@sasha-vm> <20191017075008.2uqgdimo3hrktj3i@pali> <20200213000656.hx5wdofkcpg7aoyo@pali>
 <20200213211847.GA1734@sasha-vm>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1581718578_27211P";
         micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date:   Fri, 14 Feb 2020 17:16:18 -0500
Message-ID: <86151.1581718578@turing-police>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--==_Exmh_1581718578_27211P
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, 13 Feb 2020 16:18:47 -0500, Sasha Levin said:

> >> I was hoping that it would be possible to easily use secondary FAT t=
able
> >> (from TexFAT extension) for redundancy without need to implement ful=
l
> >> TexFAT, which could be also backward compatible with systems which d=
o
> >> not implement TexFAT extension at all. Similarly like using FAT32 di=
sk
> >> with two FAT tables is possible also on system which use first FAT
> >> table.

OK.. maybe I'm not sufficiently caffeinated, but how do you use 2 FAT tab=
les on
a physical device and expect it to work properly on a system that uses ju=
st the
first FAT table, if the device is set to =22use second table=22 when you =
mount it?
That sounds just too much like the failure modes of running fsck on a mou=
nted
filesystem....

> >By the chance, is there any possibility to release TexFAT specificatio=
n?
> >Usage of more FAT tables (even for Linux) could help with data recover=
y.
>
> This would be a major pain in the arse to pull off (even more that
> releasing exFAT itself) because TexFAT is effectively dead and no one
> here cares about it. It's not even the case that there are devices whic=
h
> are now left unsupported, the whole TexFAT scheme is just dead and gone=
.
>
> Could I point you to the TexFAT patent instead
> (https://patents.google.com/patent/US7613738B2/en)? It describes well
> how TexFAT used to work.

I don't think anybody wants the full TexFAT support - but having a backup=
 copy
of the FAT would be nice in some circumstances.

Actually, that raises an question....

What the published spec says:

The File Allocation Table (FAT) region may contain up to two FATs, one in=
 the
First FAT sub-region and another in the Second FAT sub-region. The Number=
OfFats
field describes how many FATs this region contains. The valid values for =
the
NumberOfFats field are 1 and 2. Therefore, the First FAT sub-region alway=
s
contains a FAT. If the NumberOfFats field is two, then the Second FAT
sub-region also contains a FAT.

The ActiveFat field of the VolumeFlags field describes which FAT is activ=
e.
Only the VolumeFlags field in the Main Boot Sector is current. Implementa=
tions
shall treat the FAT which is not active as stale. Use of the inactive FAT=
 and
switching between FATs is implementation specific.

Sasha:  can you find out what the Windows implementation does regarding t=
hat
last sentence?  Does it actively use both FAT sub-regions and switch betw=
een
them (probably not), or does it read the ActiveFAT value and use that one=
, or
does Windows just use NumberOfFats =3D=3D 1?

I'm assuming that the fact the doc also says =22NumberOfFats =3D=3D 2 is =
only valid
for TexFAT volumes=22 possibly means =22Microsoft thinks that's hardcoded=
 at 1=22
given the death of TexFAT.  That would make adding alternate FAT support =
a
major challenge.

On the other hand, if Windows actually looks at the NumberOfFats value, f=
inds
a 2, and ActiveFAT =3D=3D1 (meaning use second table) and says =22OK, wha=
tever=22 and
just uses the second table from there on out, it becomes a lot easier.


--==_Exmh_1581718578_27211P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Comment: Exmh version 2.9.0 11/07/2018

iQIVAwUBXkccMgdmEQWDXROgAQJrXg//bPrYDkf+/qHxzc4KiI24Rxtqdm4U7Az9
dKL7V6gOwwbrxTrr+xIZvmIKJv49976Gx1CTVDVrWaXt8TssINoO9jmJlQOHMQ4P
DzgVhXgkzZuLbiJ5mFMMrNT5JLiCnx3clSkgSTVXxKXXsfKNFFtC3N6RqExxSB8R
mh3bU2o5kyu3+iIwstusdTjHOc6pyUDSTmJ4IgptP1GCiVxUmvzpeNR3MxcPPt0Y
y8gI2si8AxK9koQHPxmQxrfviTvcBhqZ9dnR+Ap+aLgdPCea1MgXW9/zReficgj/
sUsdqKOrKvS8lyIZbninbaXqht6jUdnyHmENqvmGfKDz0b5OZjFaS62OAkd1DHPM
2rtFlgRCNMVcbu3p+pxbl1QiGb+xgakOzYiQEHjKFKQRcsXNcHUp/wstMOQsboF+
SdnxDhKdK4Vagwur9ZyPeGZfHEOk1CCM4/VCNCOqs+qZo+YBqZbxC8uhMd53/fUl
231KAF796DKrCeIsMdoGSinaGJOqXvuHzQoXTPKYcpGglnvvje35DYxhkVs33WFU
U+b0IIoofQhzNBIJeniKpqNai5AsNNHjA4Mrnpp72sb5DA/Zll36RgXIn/+CG52/
aF2BJpOWIJdCa1X3KGoae3dNdU6n95ZHdTsKqh54ZeITB+El0BwB1uNyzHhgVjhI
e9fqc6Jcr+8=
=pN4u
-----END PGP SIGNATURE-----

--==_Exmh_1581718578_27211P--