From: NeilBrown Date: Fri, 13 Aug 2010 11:58:57 +0000 (+1000) Subject: README update X-Git-Url: http://git.neil.brown.name/?a=commitdiff_plain;h=5db2b7c0e96bcd7524694c72400b75a025e7871d;p=LaFS.git README update --- diff --git a/README b/README index 2c2f0ad..b2bc105 100644 --- a/README +++ b/README @@ -4975,7 +4975,7 @@ DONE 14/ Review writepage and flush and make sure we flush often enough but DONE 14a/ use bio_add_page to write clusters. -14b/ Figure out what backing_dev to presented for the filesystem. +14b/ Figure out what backing_dev to present for the filesystem. DONE 15/ The inode map file lost some credits. I think it losts a PinPending because it isn't locked properly. Don't clear PinPending if someone else might @@ -4986,7 +4986,7 @@ DONE15a/ Find all FIXMEs and add them here. DONE 15b/ Report directory size less confusingly -15c/ roll-forward should not update index if physaddr hasn't changed (roll_block) +DONE 15c/ roll-forward should not update index if physaddr hasn't changed (roll_block) DONE 15d/ What does I_Dirty mean - and implement it. @@ -5005,13 +5005,13 @@ FIXED 15e/ setattr should queue an update for the inode metadata. in erase_dblock, but that won't complete until cleaner gets to run, but this is the cleaner blocked on orphans. -15i/ separate thread management from 'cleaner' name. +DONE 15i/ separate thread management from 'cleaner' name. 15j/ review rules in getref_locked - and document them - fix accesses to iblock -15k/ newblocks should probably be a count of segments. Review that. +DONE 15k/ newblocks should probably be a count of segments. Review that. 15l/ make sure checkpoint_youth is decayed properly. Review youth decay. @@ -5172,6 +5172,21 @@ FIXED 15e/ setattr should queue an update for the inode metadata. - use new write_begin / write_end - review how we ensure that credit remain with block. +15ca/ When pin inode data block, pin it as well as index block I think + It is still kept of the leaf list until the index block is done with + I think. + +15cb/ Layout issues: + - subset filesys still needs a parent pointer + - cluster head needs mtime/ctime to log these. + - need better tracking of which devices are in this array?? + Need to be able to have read-only devices that are shared + amove arrays. + - need multiple parallel write-clusters to allow parallel writes. + - record tuning in state block: + - max_segs + + 16/ Update locking.doc 17/ cluster_flush calls lafs_cluster_allocate calls lafs_add_block_address @@ -5291,6 +5306,15 @@ DONE 52/ NFS export Can we create unique inode numbers? hard links for dev-files would be problematic. +59/ Fix NeedFlush handling so we don't drop-then-retake + a mutex and that isn't sensible. + +60/ Introduce some fs state recording that fsck is needed and possibly + identifying what sort of fsck. + +61/ Try to make the inode struct smaller - maybe move some of the + fs metadata into a separately-allocated struct. + 26June2010 Investigating 5a @@ -6305,3 +6329,87 @@ WritePhase - what is that all about? Ok, got that fixed. All seems happy again, time for a commit. +09Aug2010 + 14b/ What backing-dev to show the filesystem. + backing-dev holds: + congested state + unplug function + read-ahead info + throughput measurements + + Much of that is for generic code to use. We need to: + - provide an unplug funtion that unplugs all devices + - provide a congested function that which checks all devices, + or for 'write' - at least the device we are writing to. + + How do we set the backing device? + The 'struct address_space' point to one, as does struct super_block. + set_anon_super establishes a null bdi, set_bdev_super gets it from the + bdev->queue + + We need to bdi_init and bdi_register (if no error) our bdi. + bdi_destroy calls unregister and reverses bdi_init + or just bdi_setup_and_register + but bdi_register_dev gives a better name - isn't this sick!!! + + Partly done ... but I'm hitting more bugs :-( + + -Checkpoint cannot complete because... + Lots of dirty inodes that are orphans are not pinned!! I + guess the InoIdx is ?? + Most of them don't have InoIdx(?) Only '8' does. + 8/0 is also an orphan and is on wc[0] + + It seems that this block keeps getting re-written and stays in + Phase0. + Is that because it is a data block with PinPending.. No, that works + as long as it become un-dirty: we drop pinpending, refile, and set again + + It is being dirtied again during writeout for the checkpoint + so it doesn't get to changed phase when we lift PinPending. + I gues we mustn't dirty it if it is in the old phase. + + -And twice inode 17 is deleted without B_Orphan being set! + That is the only file that exists before we mount. + Problem was orphan_release instead of orphan_forget + I wonder why it only affected 17... + + -at shutdown we drop an inode and try to invalidate pages, but + root inode is still dirty - I wonder why. + The dblock is in a different phase to the iblock. + In checkpoint we wait until root iblock changes phase, but + not root dblock! + + + UP TO: + I'm testing subordinate filesystems, which don't work yet. + I need to create the root directory and inode map. + Obviously I cannot record the inode map file in the inode map.... + inode_map should ignore everything less than 16? 8? 2? + Need to make sure creating with a given inode number works. + Need to make make sure auto-allocate inum is never less than 16. + +11Aug2010 + How to map from filesys inode to superblock? + Need in + lafs_iget_fs + choose_free_inum - to get inode-1 + ditto in inode_map_free + lafs_put_super has something odd with i_sb + + Could do an sget search.. + Or could just store it in the inode (but not in i_sb!!) + inode already a bit large though. + Do it for now, but make a note to trim the fs_md part of inode + into a separate allocation. + + lafs_new_inode should take an 'sb' not a 'filesys'. + In fact, get rid of filesys. It is + MAP(i->i_sb->s_fs_info)->root. + + 15f - timestamps for roll-forward. + The writeout can be much later, but logging the mtime is fairly + boring ... we could log mtime in the group head, which might be cheap + enough. How much precision is needed, and against what base? + probsably mtime of last checkpoint from superblock. That should + be not more than 2048 seconds ago, so 16 bits gets is 30msec...