Hi Kiste, 2011/5/6 Oliver Seitz <[email protected]>
> > *Matt, I read in comments your FAT32 lib doesn't support fragmented files. > Do you actually try to implement this feature, and did you give up because > not enough resource ?** > * > > I feel adressed as "guy" and try to answer as much as i know ;-) > Great ! > > There are two approaches to deal with fragmented files: > > 1.) Start reading, and as soon as we reach the end of the fragment, go back > to the FAT and find the next fragment. This could need a lot of time > occasionally while reading in the middle of a file. The same FAT sector may > have to be read multiple times during acces of a single file. > > 2.) When opening, parse the FAT and collect all the fragments to a buffer. > Needs only time when opening the file, but needs a buffer that could limit > the allowable number of fragments. > > Matt chose to use this second variant, which IMO is a good choice > generally. It is not universal, however. Theoretically, a file of 2GB can > consist of four millions of fragments. The 16MByte (or more?) buffer that > would be needed is beyond anything you could reasonably connect to a PIC. > OK, back on Minix world, I chose number 1: I explore zone (ie. block) addresses from inode itself and indirectlyn while reading and writing. I understand better why fragmented files aren't supported by fat32 current impl. I could indeed do the same in a restricted version of Minix. Zone exploration is done in minix_next_zone(). I could write another simpler version which would just return address + 1. I would still need to have proper inode content to make readable on another system, so I wonder how "heavy" this version would still remain... I'll see what I do what I'm done with most importannt feature implemented (eg. I'm not going to support symlinks I think) > > This is the reason that made me think about a "new simple" file system that > uses a kind of linked list. By mixing user data and meta data in each > sector, there would be no need to neither cache fragment data nor jumping to > a system area to find the next sector. > I've no doubt about how useful such a "simple" filesystem would be ! And thus be happy to give a try when possible. Cheers, Seb -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
