On Wed, Oct 16, 2019 at 06:32:31PM +0200, Pali Rohár wrote: > 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 Ok, but given that the "only" os that can read/write the TexFAT extension is WinCE, and that os is obsolete these days, it might be hard to find images to test/validate against :) But hey, I'll take the patch if you write it, no objection! thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
