From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 25 Mar 2014 09:38:57 +0100 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9front: /lib/ndb/local clobbered after edit w/ sam, soon following update Topicbox-Message-UUID: cfb14936-ead8-11e9-9d60-3106f5b1d025 sounds like filesystem corruption, yes. in that case, do not override anything. keep it as it is and depending on the filesystem, run a check to determine the extend of the damage. what filesystem is this? if its cwfs, read further: if the damage seems small, you might just clear the directory entry for the corrupted files (abandoning the blocks) and recreate it from backup. do not just delete the file or override it! the block pointers could be wrong pointing into other files, you'll just corrupt these or put these blocks on the freelist! a filesystem check can reveal this. see fs(8) manpage for the check and clri commands. you enter these commands on the filesystem console, accessube by: con -Cl /srv/cwfs.cmd with cwfs, all changes to the filesystem are first done in the cache and later the cache is written out to the dump at night. you can recover main from the worm dump, which will reinitialize the cache. note, this assumes that the corruption is in the cache only and hasnt propagated to the worm yet. (check 9fs dump; cd /n/dump and see if the backup is still intact) to reinitialize the cache from last dump, you reboot and use bootargs local!/dev/sdXX/fscache -c to enter config mode, then in config mode enter: recover main end -- cinap