1*63374Sbostic# @(#)TODO 8.1 (Berkeley) 06/11/93 252092Sbostic 354259SbosticNOTE: Changed the lookup on a page of inodes to search from the back 454259Sbosticin case the same inode gets written twice on the same page. 554259Sbostic 654259SbosticMake sure that if you are writing a file, but not all the blocks 754259Sbosticmake it into a single segment, that you do not write the inode in 854259Sbosticthat segment. 954259Sbostic 1052092SbosticKeith: 1154258Sbostic Why not delete the lfs_bmapv call, just mark everything dirty 1254258Sbostic that isn't deleted/truncated? Get some numbers about 1354258Sbostic what percentage of the stuff that the cleaner thinks 1454258Sbostic might be live is live. If it's high, get rid of lfs_bmapv. 1555820Sbostic 1655820Sbostic There is a nasty problem in that it may take *more* room to write 1755820Sbostic the data to clean a segment than is returned by the new segment 1855820Sbostic because of indirect blocks in segment 2 being dirtied by the data 1955820Sbostic being copied into the log from segment 1. The suggested solution 2055820Sbostic at this point is to detect it when we have no space left on the 2155820Sbostic filesystem, write the extra data into the last segment (leaving 2255820Sbostic no clean ones), make it a checkpoint and shut down the file system 2355820Sbostic for fixing by a utility reading the raw partition. Argument is 2455820Sbostic that this should never happen and is practically impossible to fix 2555820Sbostic since the cleaner would have to theoretically build a model of the 2655820Sbostic entire filesystem in memory to detect the condition occurring. 2755820Sbostic A file coalescing cleaner will help avoid the problem, and one 2855820Sbostic that reads/writes from the raw disk could fix it. 2955820Sbostic 3055802SbosticDONE Currently, inodes are being flushed to disk synchronously upon 3154258Sbostic creation -- see ufs_makeinode. However, only the inode 3254258Sbostic is flushed, the directory "name" is written using VOP_BWRITE, 3354258Sbostic so it's not synchronous. Possible solutions: 1: get some 3454258Sbostic ordering in the writes so that inode/directory entries get 3554258Sbostic stuffed into the same segment. 2: do both synchronously 3654258Sbostic 3: add Mendel's information into the stream so we log 3754258Sbostic creation/deletion of inodes. 4: do some form of partial 3854258Sbostic segment when changing the inode (creation/deletion/rename). 3955802SbosticDONE Fix i_block increment for indirect blocks. 4052223Sbostic If the file system is tar'd, extracted on top of another LFS, the 4152223Sbostic IFILE ain't worth diddly. Is the cleaner writing the IFILE? 4252223Sbostic If not, let's make it read-only. 4355802SbosticDONE Delete unnecessary source from utils in main-line source tree. 4455802SbosticDONE Make sure that we're counting meta blocks in the inode i_block count. 4552223Sbostic Overlap the version and nextfree fields in the IFILE 4655802SbosticDONE Vinvalbuf (Kirk): 4752223Sbostic Why writing blocks that are no longer useful? 4852223Sbostic Are the semantics of close such that blocks have to be flushed? 4952223Sbostic How specify in the buf chain the blocks that don't need 5052223Sbostic to be written? (Different numbering of indirect blocks.) 5152092Sbostic 5252092SbosticMargo: 5355453Sbostic Change so that only search one sector of inode block file for the 5455453Sbostic inode by using sector addresses in the ifile instead of 5555453Sbostic logical disk addresses. 5655453Sbostic Fix the use of the ifile version field to use the generation 5755453Sbostic number instead. 5855802SbosticDONE Unmount; not doing a bgetvp (VHOLD) in lfs_newbuf call. 5955802SbosticDONE Document in the README file where the checkpoint information is 6052093Sbostic on disk. 6152092Sbostic Variable block sizes (Margo/Keith). 6252092Sbostic Switch the byte accounting to sector accounting. 6355802SbosticDONE Check lfs.h and make sure that the #defines/structures are all 6452092Sbostic actually needed. 6555802SbosticDONE Add a check in lfs_segment.c so that if the segment is empty, 6655802Sbostic we don't write it. 6752092Sbostic Need to keep vnode v_numoutput up to date for pending writes? 6855802SbosticDONE USENIX paper (Carl/Margo). 6952092Sbostic 7055802Sbostic 7155802SbosticEvelyn: 7252092Sbostic lfsck: If delete a file that's being executed, the version number 7352092Sbostic isn't updated, and lfsck has to figure this out; case is the same as if have an inode that no directory references, 7452092Sbostic so the file should be reattached into lost+found. 7555802Sbostic Recovery/fsck. 7655802Sbostic 7755802SbosticCarl: 7852092Sbostic Investigate: clustering of reads (if blocks in the segment are ordered, 7952092Sbostic should read them all) and writes (McVoy paper). 8052092Sbostic Investigate: should the access time be part of the IFILE: 8152092Sbostic pro: theoretically, saves disk writes 8252092Sbostic con: cacheing inodes should obviate this advantage 8352092Sbostic the IFILE is already humongous 8452092Sbostic Cleaner. 8552092Sbostic Port to OSF/1 (Carl/Keith). 8652092Sbostic Currently there's no notion of write error checking. 8752092Sbostic + Failed data/inode writes should be rescheduled (kernel level 8852092Sbostic bad blocking). 8952092Sbostic + Failed superblock writes should cause selection of new 9052092Sbostic superblock for checkpointing. 9152092Sbostic 9252092SbosticFUTURE FANTASIES: ============ 9352092Sbostic 9455802Sbostic+ unrm, versioning 9552092Sbostic+ transactions 9655802Sbostic+ extended cleaner policies (hot/cold data, data placement) 9752092Sbostic 9852092Sbostic============================== 9952092SbosticProblem with the concept of multiple buffer headers referencing the segment: 10052092SbosticPositives: 10152092Sbostic Don't lock down 1 segment per file system of physical memory. 10252092Sbostic Don't copy from buffers to segment memory. 10352092Sbostic Don't tie down the bus to transfer 1M. 10452092Sbostic Works on controllers supporting less than large transfers. 10552092Sbostic Disk can start writing immediately instead of waiting 1/2 rotation 10652092Sbostic and the full transfer. 10752092SbosticNegatives: 10852092Sbostic Have to do segment write then segment summary write, since the latter 10952092Sbostic is what verifies that the segment is okay. (Is there another way 11052092Sbostic to do this?) 11152092Sbostic============================== 11252092Sbostic 11352092SbosticThe algorithm for selecting the disk addresses of the super-blocks 11452092Sbostichas to be available to the user program which checks the file system. 11552092Sbostic 11652092Sbostic(Currently in newfs, becomes a common subroutine.) 117