1# @(#)TODO 5.8 (Berkeley) 07/20/92 2 3NOTE: Changed the lookup on a page of inodes to search from the back 4in case the same inode gets written twice on the same page. 5 6I don't think we still need the next segment pointer in the LFS summary 7block. (TK) 8 9Make sure that if you are writing a file, but not all the blocks 10make it into a single segment, that you do not write the inode in 11that segment. 12 13I added a hack to vinvalbuf to check for lfs -- I believe that 14vinvalbuf should be a vnode op. 15 16Keith: 17 Why not delete the lfs_bmapv call, just mark everything dirty 18 that isn't deleted/truncated? Get some numbers about 19 what percentage of the stuff that the cleaner thinks 20 might be live is live. If it's high, get rid of lfs_bmapv. 21* Currently, inodes are being flushed to disk synchronously upon 22 creation -- see ufs_makeinode. However, only the inode 23 is flushed, the directory "name" is written using VOP_BWRITE, 24 so it's not synchronous. Possible solutions: 1: get some 25 ordering in the writes so that inode/directory entries get 26 stuffed into the same segment. 2: do both synchronously 27 3: add Mendel's information into the stream so we log 28 creation/deletion of inodes. 4: do some form of partial 29 segment when changing the inode (creation/deletion/rename). 30 Fix i_block increment for indirect blocks. 31 If the file system is tar'd, extracted on top of another LFS, the 32 IFILE ain't worth diddly. Is the cleaner writing the IFILE? 33 If not, let's make it read-only. 34 Delete unnecessary source from utils in main-line source tree. 35 Make sure that we're counting meta blocks in the inode i_block count. 36 Overlap the version and nextfree fields in the IFILE 37 Vinvalbuf (Kirk): 38 Why writing blocks that are no longer useful? 39 Are the semantics of close such that blocks have to be flushed? 40 How specify in the buf chain the blocks that don't need 41 to be written? (Different numbering of indirect blocks.) 42 43Margo: 44 Change so that only search one sector of inode block file for the 45 inode by using sector addresses in the ifile instead of 46 logical disk addresses. 47 Fix the use of the ifile version field to use the generation 48 number instead. 49* Unmount; not doing a bgetvp (VHOLD) in lfs_newbuf call. 50 Document in the README file where the checkpoint information is 51 on disk. 52 Variable block sizes (Margo/Keith). 53 Switch the byte accounting to sector accounting. 54 Check lfs.h and make sure that the #defines/structures are all 55 actually needed. 56* Add a check in lfs_segment.c so that if the segment is empty, 57 we don't write it. (Margo, do you remember what this 58 meant? TK) 59 Need to keep vnode v_numoutput up to date for pending writes? 60 61Carl: 62 lfsck: If delete a file that's being executed, the version number 63 isn't updated, and lfsck has to figure this out; case is the same as if have an inode that no directory references, 64 so the file should be reattached into lost+found. 65 USENIX paper (Carl/Margo). 66 Investigate: clustering of reads (if blocks in the segment are ordered, 67 should read them all) and writes (McVoy paper). 68 Investigate: should the access time be part of the IFILE: 69 pro: theoretically, saves disk writes 70 con: cacheing inodes should obviate this advantage 71 the IFILE is already humongous 72 Cleaner. 73 Recovery/fsck. 74 Port to OSF/1 (Carl/Keith). 75 Currently there's no notion of write error checking. 76 + Failed data/inode writes should be rescheduled (kernel level 77 bad blocking). 78 + Failed superblock writes should cause selection of new 79 superblock for checkpointing. 80 81FUTURE FANTASIES: ============ 82 83+ unrm 84 - versioning 85+ transactions 86+ extended cleaner policies 87 - hot/cold data, data placement 88 89============================== 90Problem with the concept of multiple buffer headers referencing the segment: 91Positives: 92 Don't lock down 1 segment per file system of physical memory. 93 Don't copy from buffers to segment memory. 94 Don't tie down the bus to transfer 1M. 95 Works on controllers supporting less than large transfers. 96 Disk can start writing immediately instead of waiting 1/2 rotation 97 and the full transfer. 98Negatives: 99 Have to do segment write then segment summary write, since the latter 100 is what verifies that the segment is okay. (Is there another way 101 to do this?) 102============================== 103 104We don't plan on doing the DIROP log until we try to do roll-forward. 105This is part of what happens if random blocks get trashed and we try to 106recover, i.e. the same information that DIROP tries to provided is 107required for general recovery. I believe that we're going to need an 108fsck-like tool that resolves the disk (possibly a combination of 109resolution, checkpoints and checksums). The problem is that the current 110implementation does not handle the destruction of, for example, the root 111inode. 112============================== 113 114The algorithm for selecting the disk addresses of the super-blocks 115has to be available to the user program which checks the file system. 116 117(Currently in newfs, becomes a common subroutine.) 118