Take the following cluster chain: 2 -> 3 -> 4 -> EOF
Then the FAT refered table contains: table[4] -> 3 table[3] -> 2 table[2] -> 0 Well on FAT32 the labels are normaly 28bit, but that shouldn't realy matter. The FAT refered map is used to directly know wether to consult the FAT refered table or the DIR refered table. Imre >----- Oorspronkelijk bericht ----- >Van: Alain M. [mailto:[EMAIL PROTECTED] >Verzonden: woensdag, maart 19, 2008 07:49 PM >Aan: [email protected] >Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods (OT) > >Interesting... > >What information is tored in the "FAT refered table" it needs 32 bits? > >Alain > >Imre Leber escreveu: >> Here are the numbers for the data structures used by defrag, when calculated >> for FAT32. >> >> Cluster movable map: 32 MB (fat size * 1 bit) >> FAT refered map: 32MB (fat size * 1 bit) >> FAT refered table: 1024MB (fat size * 4 byte) >> Dir refered table (take 100000 files): (# files * 6 bytes) 0,5 MB >> >> total: 1088,5 MB (and I though XMS only went to 64MB) >> >> In depth: >> >> Cluster movable map: indicates which clusters are movable. >> FAT refered map: indicates which clusters are refered to in the FAT >> FAT refered table: stores the back pointers for the FAT clusters >> DIR refered table: stores the back pointers for the directory refered >> clusters >> >> Imre >> >>> ----- Oorspronkelijk bericht ----- >>> Van: Eric Auer [mailto:[EMAIL PROTECTED] >>> Verzonden: dinsdag, maart 18, 2008 10:22 PM >>> Aan: [email protected] >>> Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods (OT) >>> >>> >>> Hi! >>> >>>> For this it is very sad that FreeDOS does not use the LEAN file system >>>> (http://freedos-32.sourceforge.net/doc/lean.html) instead. That has back >>>> pointers for pretty much everything and would as a consequence be much >>>> faster. >>> A lean ad ;-). But you can just as well build data structures with the >>> back pointers in RAM while defrag and similar tools are running. Takes >>> roughly the same amount of RAM as the metadata (FAT, dir) takes on >>> disk. As you often copy those to RAM for work like defragging to get >>> fast access, you basically get some overhead for making the pointers >>> plus you double the amount of RAM that defrag consumes ;-). >>> >>> Note that for example DOSFSCK takes several times the size of your FAT >>> plus several times the size of all directory entries of RAM, too. >>> Actually this would be interesting to know more about: Could some of >>> you run DOSFSCK 2.11c with the -v option on large filesystems, with >>> many files and/or many clusters, and report how much heap it tells >>> you that it has used? It is displayed when DOSFSCK is done. Seems to >>> be 5..10 times the FAT size for systems with few files here... Some >>> "bad case of FAT16" would be interesting (might use 1-5 MB maybe?) >>> as well as, of course, typical FAT32 filesystems. You can find >>> DOSFSCK version 2.11c on my page, as usual: >>> www.coli.uni-saarland.de/~eric/stuff/soft/by-others/dosdosfsck-2.11c.zip >>> (you should already have cwsdpmi anyway, otherwise see e.g. my page) >>> >>> Eric >>> > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Microsoft >Defy all challenges. Microsoft(R) Visual Studio 2008. >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >_______________________________________________ >Freedos-devel mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/freedos-devel > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
