1# @(#)TODO 5.2 (Berkeley) 12/31/91 2 3TODO: ======================= 4 5Keith: 6 XXX The problem is that the IFILE vnode isn't getting entered into 7 the vnode cache (nor is the underlying inode being placed into 8 the inode cache). Q: Should the underlying inode be in the 9 inode cache (does it get flushed)? Q: Should the mount code 10 update the ifile inode slot to reflect the current disk address? 11 12 Move utils into main-line source. 13 14Margo: 15 See if lfs_mountfs can just call lfs_vget for IFILE vnode 16 by minor hack to lfs_itod. 17 Unmount; not doing a bgetvp (VHOLD) in lfs_newbuf call. 18 Document in the README file where the checkpoint information is 19 on disk. 20 Variable block sizes (Margo/Keith). 21 Switch the byte accounting to sector accounting. 22 Check lfs.h and make sure that the #defines/structures are all 23 actually needed. 24 Add a check in lfs_segment.c so that if the segment is empty, 25 we don't write it. (Margo, do you remember what this 26 meant? TK) 27 Need to keep vnode v_numoutput up to date for pending writes? 28 29Carl: 30 lfsck: If delete a file that's being executed, the version number 31 isn't updated, and lfsck has to figure this out; case is the same as if have an inode that no directory references, 32 so the file should be reattached into lost+found. 33 USENIX paper (Carl/Margo). 34 Investigate: clustering of reads (if blocks in the segment are ordered, 35 should read them all) and writes (McVoy paper). 36 Investigate: should the access time be part of the IFILE: 37 pro: theoretically, saves disk writes 38 con: cacheing inodes should obviate this advantage 39 the IFILE is already humongous 40 Cleaner. 41 Recovery/fsck. 42 Port to OSF/1 (Carl/Keith). 43 Currently there's no notion of write error checking. 44 + Failed data/inode writes should be rescheduled (kernel level 45 bad blocking). 46 + Failed superblock writes should cause selection of new 47 superblock for checkpointing. 48 49FUTURE FANTASIES: ============ 50 51+ unrm 52 - versioning 53+ transactions 54+ extended cleaner policies 55 - hot/cold data, data placement 56 57============================== 58Problem with the concept of multiple buffer headers referencing the segment: 59Positives: 60 Don't lock down 1 segment per file system of physical memory. 61 Don't copy from buffers to segment memory. 62 Don't tie down the bus to transfer 1M. 63 Works on controllers supporting less than large transfers. 64 Disk can start writing immediately instead of waiting 1/2 rotation 65 and the full transfer. 66Negatives: 67 Have to do segment write then segment summary write, since the latter 68 is what verifies that the segment is okay. (Is there another way 69 to do this?) 70============================== 71 72We don't plan on doing the DIROP log until we try to do roll-forward. 73This is part of what happens if random blocks get trashed and we try to 74recover, i.e. the same information that DIROP tries to provided is 75required for general recovery. I believe that we're going to need an 76fsck-like tool that resolves the disk (possibly a combination of 77resolution, checkpoints and checksums). The problem is that the current 78implementation does not handle the destruction of, for example, the root 79inode. 80============================== 81 82The algorithm for selecting the disk addresses of the super-blocks 83has to be available to the user program which checks the file system. 84 85(Currently in newfs, becomes a common subroutine.) 86