On Friday 14 February 2020 17:16:18 Valdis Klētnieks wrote: > 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 table > > >> (from TexFAT extension) for redundancy without need to implement full > > >> TexFAT, which could be also backward compatible with systems which do > > >> not implement TexFAT extension at all. Similarly like using FAT32 disk > > >> 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 tables on > a physical device and expect it to work properly on a system that uses just the > first FAT table, if the device is set to "use second table" when you mount it? > That sounds just too much like the failure modes of running fsck on a mounted > filesystem.... Idea is simple. Expects that we have a clean filesystem in correct state. We load primary/active/main FAT table (just call it FAT1) and all changes to filesystem would be done via second non-active FAT table (FAT2). At unmount or sync or flush buffer times, FAT2 would be copied back to the FAT1 and filesystem would be back in clean state. So this should not break support for implementations which use just FAT1. And if above implementation which use both FAT1 and FAT2 "crash" during write operations to FAT2 it may be possible to reconstruct and repair some parts of filesystem from FAT1 (as it would contain previous state of some filesystem parts). Via dirty bit can be detected if proper unmount occurred or not, and fsck implementation could do use this fact and try to do repairing (possible by asking user what should do). Of course if implementation use only FAT1 we cannot use FAT2 for repairing and therefore fsck should really ask user if it should use FAT2 for repair or not. If implementation use only FAT1, does not crash and let filesystem in clean/correct state then there should not be any problem for implementation which can use both FATs as it reads main state from FAT1. Therefore these two implementations should be compatible and problem can happen only if they let filesystem in inconsistent state. (But if they let it in inconsistent state, then any implementation may have troubles and fsck is needed). I hope that it is more clear now... > > >By the chance, is there any possibility to release TexFAT specification? > > >Usage of more FAT tables (even for Linux) could help with data recovery. > > > > 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 which > > 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. Main problem is that we do not know what "full TexFAT support" means as currently it is secret. My original question for TexFAT was also because of NumberOfFats set to 2 is according to released exFAT specification possible only for TexFAT volumes. And from reading whole exFAT specification I see that better data recovery can be achieved only by having backup copy of FAT table (and allocation bitmap), which is limited to (currently undocumented) TexFAT extension. -- Pali Rohár pali.rohar@xxxxxxxxx
