On 3/1/2018 9:41 AM, Michal Švamberg wrote: > Hi, > in volume are inaccesible files and client wrote message: > [ 56.306458] afs: FetchStatus ec 0 iv 1 ft 0 pv 947 pu 17570 > [ 56.306461] afs: Invalid AFSFetchStatus from server 147.228.54.17 > [ 56.306463] afs: This suggests the server may be sending bad data > that can lead to availability issues or data corruption. The issue has > been avoided for now, but it may not always be detectable. Please > upgrade the server if possible. > [ 56.306469] afs: Waiting for busy volume 875764977 (user.wimmer) in > cell zcu.cz <http://zcu.cz>
As recorded on disk, the file type for 875764977.947.17570 is 0 (invalid). As such, it is neither a directory, a file, a symlink nor a mount point and cannot be processed by the client. > I try bos salvage, vos move, vos dump & restore, but nothing help to me. The salvager doesn't know how to fix vnode's whose on-disk meta data contains an invalid vnode type. Moving, dumping and restoring the volume will simply move, dump and restore the vnode with the invalid type value. These are the available options: 1. restore the volume from a backup prior to the introduction of the on-disk damage. If vnode 875764977.947.17570 is damaged then it is possible that other vnodes are as well. 2. edit the vnode metadata stored in the vice partition 3. delete the damaged vnode by removing its directory entry and restoring the file data from backup or other sources 4. delete the vnode in the vice partition and salvage to cleanup the directory The warning message from the client is misleading in that the fileserver is not generating bogus information but the data on-disk is already bogus. Jeffrey Altman AuriStor, Inc.
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
