Brian Chu
Email: <chub AT FreeBSD DOT org>
- IRC: roasted (Efnet)
Project
I'm working on the msdosfs driver for Summer of Code 2007, and am being mentored by KonstantinBelousov.
TODO List, Ordered by Priority
The following are snippets that Konstantin has managed to gather for me about my project.
- Making the driver MPSAFE by identifying the structures to sleep on and killing all references to the GIANT LOCK.
- 2007-07-11: Bumped to having the highest priority since Bruce Evans had brought up that calls to the Giant Lock are not honored in the current kernel, which I was not aware of.
msdsofs has been broken since Giant locking for file systems (or syscalls) was removed. It allows multiple threads to race accessing the shared static buffer `nambuf' and related variables. This causes remarkably few problems. One case that breaks reliably is concurrent tars or finds, especially with a small cluster size, even on a UP system. Then getdirentries() returns garbage entries and/or lookup() of correct entries can't find things. On my UP system, I think the race occurs mainly when getdirentries() blocks on i/o and a directory entry spans the block boundary. Then another getdirentries() or lookup() can run, and if it does then it will almost certainly corrupt the state for the blocked getdirentries(). On SMP systems, I think the race occurs much more often and suspect that it is more harmful. Quick fix for an old version of FreeBSD. The part in msdosfs_lookup.c has not been tested at runtime. The part in msdosfs_vnops.c may also fix bugs involving cookie handling (but not a memory leak like I first thought?). msdosfs_lookup.c is harder to fix because it has no common cleanup code. [...] Please fix this better. mbnambuf_init() could return a non-static buffer that doesn't require locking. Deallocation would be painful. Note that even the details for Giant locking can't be hidden in msdosfs_conv.c like the current interfaces intend, since mbnambuf_init() is used a lot to reinitialize an in-use buffer, and there is no interface to drop usage.
- Investigate how Darwin accepts a broader range of FAT volumes (Robert Watson)
- 2007-07-11: I've bumped this higher.
It turns out that quite a bit of our historical sanity checking on msdosfs is too conservative when applied to the highly diverse set of FAT file systems in the field. I think it would be useful for someone(tm) to compare the sanity checks in our version of msdosfs and the checks in the Darwin version and see what they've had to remove.
- Implementing Extended Attributes. A snipplet sent by Pedro, from a OS/2 handbook:
EXTENDED ATTRIBUTES IN THE FAT FILE SYSTEM OS/2 supports Extended Attributes (EAs) in the FAT filesystem, as well as in the HPFS file system. EAs can be composed of up to 64 KB of data relatied to the file. Because of the potential size of these EAs, they cannot be stored in a file's directory entry. OS/2 uses reserved space in each file's directory entry to contain pointers to the EAs. The EAs themselves are stored in your root directory in a file called EA_DATA_SF, which has Hidden, System, and Read Only attributes. Note that the file EA_DATA_SF has two blank spaces represented here by the underscore characters (_) for clarity. DOS and DOS applications do not recognize filenames with embedded blank spaces because the blank is not a valid file-name character in DOS. The blank character is a valid filename in OS/2, however, even on a FAT drive. More details: http://www.tavi.co.uk/os2pages/eadata.html
Tasks needing review
- Consolidate FAT data structure definitions. From Poul-Henning Kamp:
> I have en ancient entry in my TODO list that says that we have > the FAT filesystem data structures defined three places in our > source tree, and that one should be enough. > > For the life of me, I can't remember what the third place is, > but the first two must be: > fsck_msdosfs > sys/fs/msdosfs > > For some reason, I think mksdos_fs is not the third one, it could > possibly be geom_label, but I'm not sure.