- XXX The problem is that the IFILE vnode isn't getting entered into
- the vnode cache (nor is the underlying inode being placed into
- the inode cache). Q: Should the underlying inode be in the
- inode cache (does it get flushed)? Q: Should the mount code
- update the ifile inode slot to reflect the current disk address?
-
- Move utils into main-line source.
+ Why not delete the lfs_bmapv call, just mark everything dirty
+ that isn't deleted/truncated? Get some numbers about
+ what percentage of the stuff that the cleaner thinks
+ might be live is live. If it's high, get rid of lfs_bmapv.
+ Currently, inodes are being flushed to disk synchronously upon
+ creation -- see ufs_makeinode. However, only the inode
+ is flushed, the directory "name" is written using VOP_BWRITE,
+ so it's not synchronous. Possible solutions: 1: get some
+ ordering in the writes so that inode/directory entries get
+ stuffed into the same segment. 2: do both synchronously
+ 3: add Mendel's information into the stream so we log
+ creation/deletion of inodes. 4: do some form of partial
+ segment when changing the inode (creation/deletion/rename).
+ Fix i_block increment for indirect blocks.
+ If the file system is tar'd, extracted on top of another LFS, the
+ IFILE ain't worth diddly. Is the cleaner writing the IFILE?
+ If not, let's make it read-only.
+ Delete unnecessary source from utils in main-line source tree.
+ Make sure that we're counting meta blocks in the inode i_block count.
+ Overlap the version and nextfree fields in the IFILE
+ Vinvalbuf (Kirk):
+ Why writing blocks that are no longer useful?
+ Are the semantics of close such that blocks have to be flushed?
+ How specify in the buf chain the blocks that don't need
+ to be written? (Different numbering of indirect blocks.)