0

I'm on FreeBSD8. I have a problem with a partition. I can't mount it. It says "Operation not permitted."

I run fsck -t ufs /dev/da0p1. After it finish the operation, I can mount it successfully. But there is no any data in the partition now. I don't know if it had some data or not.

Q: run fsck on unmounted partition. Can it cause data loss? and if yes, is there a way to recover it?

edit: I run only fsck -t ufs /dev/da0p1. No -y or -n and when it ran, it printed Phase1,2,3,4,... and finish successfully. There is no prompt along the way.

teerapap
  • 101
  • 1
  • 4
  • Wow, read that title a little too quickly while needing sleep. The letters kinda just blurred together. Was ready to edit some 4 letter words out! – squillman Jan 21 '10 at 04:17

2 Answers2

1

It depends on what you said "yes" to. Without knowing a lot more about your filesystem, what was on it, and what it displayed and asked while fsck'ing, it will be very hard to answer usefully.

The short answer is yes, it can remove data. It tries very hard not to by putting stuff it finds in lost+found on that drive, but it is recovering from a filesystem which is apparently corrupted. In other words, when you're dealing with FS corruption, anything may be lost.

Michael Graff
  • 6,668
  • 1
  • 24
  • 36
0

Technically fsck attempts to identify and fix problems with the filesystem's metadata which is the data structure that describes the filesystem and consists mostly of pointers to the files, directories, permission/security objects, and the file data. It doesn't really do much with the data itself it's just there for the ride. As Michael mentioned in his answer....what changes fsck will make to the metadata depends on what options it was run with and how you answered any prompts along the way.

If you're lucky your data is in lost+found pretty much untouched. But most of the time if something ends up in lost+found then the file is either corrupt or has been separated from at least some of it's metadata. So the file may not know what directory it belongs to or the file name...in which case it will just be the inode number of the file. While it's not impossible to put things back together from this it will take a lot of effort, time, and luck.

3dinfluence
  • 12,449
  • 2
  • 28
  • 41