From d6583bb2a13f329cf0332ef2570eb8bb8fc0e39c Mon Sep 17 00:00:00 2001 From: Theo de Raadt Date: Wed, 18 Oct 1995 08:53:40 +0000 Subject: initial import of NetBSD tree --- sys/ufs/lfs/TODO | 118 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 sys/ufs/lfs/TODO (limited to 'sys/ufs/lfs/TODO') diff --git a/sys/ufs/lfs/TODO b/sys/ufs/lfs/TODO new file mode 100644 index 00000000000..7608aa2ce03 --- /dev/null +++ b/sys/ufs/lfs/TODO @@ -0,0 +1,118 @@ +# $NetBSD: TODO,v 1.2 1994/06/29 06:46:45 cgd Exp $ + +# @(#)TODO 8.1 (Berkeley) 6/11/93 + +NOTE: Changed the lookup on a page of inodes to search from the back +in case the same inode gets written twice on the same page. + +Make sure that if you are writing a file, but not all the blocks +make it into a single segment, that you do not write the inode in +that segment. + +Keith: + 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. + + There is a nasty problem in that it may take *more* room to write + the data to clean a segment than is returned by the new segment + because of indirect blocks in segment 2 being dirtied by the data + being copied into the log from segment 1. The suggested solution + at this point is to detect it when we have no space left on the + filesystem, write the extra data into the last segment (leaving + no clean ones), make it a checkpoint and shut down the file system + for fixing by a utility reading the raw partition. Argument is + that this should never happen and is practically impossible to fix + since the cleaner would have to theoretically build a model of the + entire filesystem in memory to detect the condition occurring. + A file coalescing cleaner will help avoid the problem, and one + that reads/writes from the raw disk could fix it. + +DONE 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). +DONE 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. +DONE Delete unnecessary source from utils in main-line source tree. +DONE Make sure that we're counting meta blocks in the inode i_block count. + Overlap the version and nextfree fields in the IFILE +DONE 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.) + +Margo: + Change so that only search one sector of inode block file for the + inode by using sector addresses in the ifile instead of + logical disk addresses. + Fix the use of the ifile version field to use the generation + number instead. +DONE Unmount; not doing a bgetvp (VHOLD) in lfs_newbuf call. +DONE Document in the README file where the checkpoint information is + on disk. + Variable block sizes (Margo/Keith). + Switch the byte accounting to sector accounting. +DONE Check lfs.h and make sure that the #defines/structures are all + actually needed. +DONE Add a check in lfs_segment.c so that if the segment is empty, + we don't write it. + Need to keep vnode v_numoutput up to date for pending writes? +DONE USENIX paper (Carl/Margo). + + +Evelyn: + lfsck: If delete a file that's being executed, the version number + isn't updated, and lfsck has to figure this out; case is the same as if have an inode that no directory references, + so the file should be reattached into lost+found. + Recovery/fsck. + +Carl: + Investigate: clustering of reads (if blocks in the segment are ordered, + should read them all) and writes (McVoy paper). + Investigate: should the access time be part of the IFILE: + pro: theoretically, saves disk writes + con: cacheing inodes should obviate this advantage + the IFILE is already humongous + Cleaner. + Port to OSF/1 (Carl/Keith). + Currently there's no notion of write error checking. + + Failed data/inode writes should be rescheduled (kernel level + bad blocking). + + Failed superblock writes should cause selection of new + superblock for checkpointing. + +FUTURE FANTASIES: ============ + ++ unrm, versioning ++ transactions ++ extended cleaner policies (hot/cold data, data placement) + +============================== +Problem with the concept of multiple buffer headers referencing the segment: +Positives: + Don't lock down 1 segment per file system of physical memory. + Don't copy from buffers to segment memory. + Don't tie down the bus to transfer 1M. + Works on controllers supporting less than large transfers. + Disk can start writing immediately instead of waiting 1/2 rotation + and the full transfer. +Negatives: + Have to do segment write then segment summary write, since the latter + is what verifies that the segment is okay. (Is there another way + to do this?) +============================== + +The algorithm for selecting the disk addresses of the super-blocks +has to be available to the user program which checks the file system. + +(Currently in newfs, becomes a common subroutine.) -- cgit v1.2.3