You are not logged in.
Hello!
The problem I have seems quite strange:
My dropbox sync folder in my home directory had some rough times, resyncing to dropbox, dropbox crashing, trying again, idling on synchronization....
until I decided to simply delete everything in this folder and set up the dropbox sync again.
That dosen't work. I can rename the old folder but I cannot delete every file in it.
Obviously there are some broken files:
"ls -la" shows
...
-????????? ? ? ? ? ? example.pdf
...
Now I cannot delete these files with "sudo rm",
I get a "stale file handle" error - it is not possible to check file.
This is on a btrfs file system on the latest kernel.
It is annoying but no real problem until I try to reboot:
...
btrfs: could not do orphan cleanup
...
and after this message boot fails.
"btrfs check /dev/sda2" says
...
checking extents
....
and then fails silently, no error output just the hint that it failed.
Now the strange/funny part:
I can mount the partition with "ro,recovery" and after that "rw,remount" and everything runs fine again except the mentioned broken/orphaned files still cannot be deleted, read or otherwise manipulated...
Though I am glad that I can still run my system, I am very worried that more errors might come from this and I would like to fix it somehow.
The fact that I cannot run "btrfs check" anymore is even more scary. One post somewhere mentioned to try "btrfs-zero-log" but I am not brave enough to do that as even though there is a backup I don't want to recover 1.5 TB of files...
Also booting with remounting at every boot is not very convenient....
thx for reading, plz help someone,
piedro
Last edited by piedro (2015-02-08 18:18:21)
Offline
Hi piedro,
maybe this would be helpful.
Simplicity is prerequisite for reliability.
Offline
thx for the link!
Though it does not help me much.
"ls -i" cannot list the files - I get:
ls: access not possible: old file access number (file handle)
(something lke this, I've had to translate....)
There has to be a file system problem associated with this...
p.
Offline
Sorry for the late reply... If that (deleting with inode) didn't work maybe you should try repairing your disk with fsck.
Have a look at the following
https://bbs.archlinux.org/viewtopic.php?id=96023
If this refers to your primary disk you cannot run fsck while it is mounted. You should unmount and then check.
Last edited by xaris (2014-06-02 21:58:41)
Simplicity is prerequisite for reliability.
Offline
The right way to repair it can be found in the problem FAQ of the Btrfs-Wiki here:
https://btrfs.wiki.kernel.org/index.php … _directory
Sadly even this hasn't worked since there hasn't been any reference to the directory size...
Now I kept the disk untouched until this year but in hindsight I think the best way in cases like this is:
- get a spare disk
- recover all data with btrfs -recover (check the Wikis first)
- reformat the faulty disk (after verifying your recovered data!)
- play back your data
The above seems like too much trouble but trust me this is much faster than trying to fix the described problem.
sorry for the late solution (on the other hand it's my own thread...),
solved,
piedro
Offline