On Wednesday 16 October 2019 09:22:11 Greg Kroah-Hartman wrote: > On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote: > > > Can I assume you will be implementing TexFAT support once the spec is > > > available? > > > > I cannot promise that I would implement something which I do not know > > how is working... It depends on how complicated TexFAT is and also how > > future exfat support in kernel would look like. > > > > But I'm interesting in implementing it. > > What devices need TexFAT? I thought it the old devices that used it are > long obsolete and gone. How is this feature going to be tested/used? Hi Greg! Per 3.1.16 of exFAT specification [1], TexFAT extension is the only way how to use more FAT tables, like in FAT32 (where you normally have two FATs). Secondary FAT table can be used e.g. for redundancy or data recovery. For FAT32 volumes, e.g. fsck.fat uses secondary FAT table when first one is corrupted. Usage of just one FAT table in exFAT is just step backward from FAT32 as secondary FAT table is sometimes the only way how to recover broken FAT fs. So I do not think that exFAT is for old devices, but rather non-exFAT is for old devices. Modern filesystems have journal or other technique to do (fast|some) recovery, exFAT has nothing. And how is this feature going to be used? That depends on specification. [1] - https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification#3116-numberoffats-field -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
