reparing / editing filesystem while mounted

[Enrico Weigelt]

Hi folks,


I've sometimes the situation where I'd like to edit or fsck a 
currently mounted filesystem. Of course this really dangerous.

It would be great if there was an API for low-level filesystem 
access, ie. directly changing data blocks, directory entries, 
inodes, etc. The (modified) fs driver sitting behind it can so
take care that we dont have collision with the other fs operations,
ie. proper locking, buffer flushing, etc.
The modified fsck now entirely works with this API.


This API for example could provide:

    + superblock access

    + directory changes w/o inode access
	-> sometimes we've got broken dirents which cannot be 
	   changed/removed by normal fs operation (unlink(),etc)
	   often the user's already happy with clearing them.
	-> if we've got a lost inode, we can connect it to some
	   dir (ie /lost+found) manually this way

    + inode changes
	-> undeleting inodes
	-> fixing wrong refcnts
	-> clearing broken inodes / block tables, etc.

    ...

We probably need some journaling/messaging system so the kernel
can tell the userland fsck when something important changes, ie. 
if we're checking directory connectivity and some dirent changes.


Of course this would all be very fs specific. But its implemented
at least for the most important disk fs'es (ie ext2/3) it would 
be a great help for people running 24/7 online systems.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact@xxxxxxxx
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/