Re: Unmountable btrfs filesystem - 'unable to find logical' / 'no mapping'

[Duncan <1i5t5.duncan@cox.net>]

Gareth Clay posted on Thu, 17 Jul 2014 23:09:08 +0000 as excerpted:

> I'm not fully sure about the btrfs restore -x behaviour either.
> Ownership of the restored files is still  incorrect, but maybe it
> affects r/w/x permissions, which look fairly sensible for the small set
> of files  I've looked at so far...

Thanks and good to read that you eventually able to successfully restore 
most of the files too.  A wakeup call indeed!  I've always stressed 
backups with btrfs and did have them, so wouldn't have been too bad off 
if I had to revert to them.  I'd simply let them get inconveniently 
outdated, and between that and the chance it gave me to actually get real 
experience with btrfs restore, I decided to try it first.

But your reply reminded me...

Something think I forgot to mention is that btrfs restore didn't restore 
symlinks, at all, not as symlinks and not as copies of the files they 
pointed at.  It was as if the symlinks simply didn't exist on the source 
filesystem I was restoring from, so I'm guessing the implementation 
simply overlooked symlinks as something it needed to deal with.

Meanwhile, on ownership/permissions I think btrfs restore must simply 
find the data and write it out as the user (presumably root) it is run 
as, using the existing umask, just as a normal user file write would do 
by default.  So if your root and user umasks are identical (presumably 
0022), you probably won't notice the permissions difference.  My root 
umask is 0022 while my user umask is 0027, so I noticed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman