17

When running

e2fsck -cck /dev/mapper/xxx

I am prompted with

 has 487 multiply-claimed block(s), shared with 84 file(s): 
 ... (inode #221446306, mod time Tue Feb 20 19:48:38 2018) 
 ... (inode #221446305, mod time Tue Feb 20 19:48:32 2018) 
 ... (inode #221446304, mod time Tue Feb 20 19:48:38 2018) 
 ... (inode #221446303, mod time Tue Feb 20 19:48:12 2018) 
 ... (inode #221446302, mod time Tue Feb 20 19:59:04 2018) 
 ... (inode #221446300, mod time Tue Feb 20 19:47:52 2018) 
Clone multiply-claimed blocks<y>?

What will be the possible consequence of continuing with "yes"? Will there be complete data loss? What is the result if continue with "no"?

AdminBee
  • 21,637
  • 21
  • 47
  • 71
john test
  • 173
  • 1
  • 1
  • 4

1 Answers1

23

Multiply-claimed blocks are blocks which are used by multiple files, when they shouldn’t be. One consequence of that is that changes to one of those files, in one of the affected blocks, will also appear as changes to the files which share the blocks, which isn’t what you want. (Hard links are a different scenario, which doesn’t show up here.)

If there is data loss here, it has already occurred, and it won’t easily be reversible; but it could be made worse...

If you answer “no” to the fsck question, the file system will remain in an inconsistent state. If you answer “yes”, then fsck will copy the shared blocks so that they can be re-allocated to a single file — with the 84 files involved here, each block would be copied 83 times. This will avoid future data loss, since changes to files will be limited to each individual file, as you’d expect. However cloning the blocks could involve overwriting data in other blocks, which currently appear to be unused, but might contain data you want to keep.

So the traditional data-recovery advice applies: if you think you need to recover data from the file system, do not touch it; make a copy of it on another disk and work on that to recover the data. The scenario here where this might be desirable is as follows. Files A and B used to be separate, but following some corruption somewhere, file B now shares blocks with file A. If nothing has overwritten file B’s old blocks, the data is still there, but it is no longer accessible. As long as nothing overwrites those blocks, they can be recovered (with a fair amount of effort perhaps). But once they’re overwritten, they’re gone; and here, cloning the shared blocks from file A could overwrite the old data...

In summary, if you have backups, or you know that the data can be recovered easily, answer “yes”. Otherwise, stop fsck, copy the file system somewhere else, and if you need the system back up and running, run fsck again and answer “yes” (and recover the data from the copy). If the data is important and needs to be recovered, copy the file system somewhere else, but leave the original alone — if you need the system back up and running, make another copy and run the system off of that, after running fsck on it.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • I would really hope that e2fsck is smart enough to repair things in the correct order so it knows unused is really unused. If not, no, finish, run again, yes is definitely safe unless other problems are also found. – Joshua Mar 13 '19 at 15:27
  • @Joshua of course it knows what’s unused. But it doesn’t know what blocks contain data which used to be a part of a file’s extents, and are now marked as unused even though they contain data which is of value to the user. My point is that this error indicates that data has been lost; but there’s still a chance it’s somewhere on disk, and letting `fsck` clone blocks risks overwriting that. – Stephen Kitt Mar 13 '19 at 15:35
  • The only time I've seen this is when the zmap had been trashed, causing the blocks to be allocated twice. The data never was in free blocks. I guess this could hit indirect blocks, in which case that's going to be really hard to recover. – Joshua Mar 13 '19 at 15:44