Receive "directory not empty" bug

Receive "directory not empty" bug

[Ames Cornish]

Hi,

btrfs is consistently refusing to receive send of certain directories.
It fails with the message "Directory not empty" for an internal
directory on the receiving side.  Any ideas on what this might be or
how to troubleshoot it?

Here's an example:

btrfs-progs v3.19-rc2
root@ProLiant:/mnt/backup/bug# uname -a
Linux ProLiant 3.18.7-031807-generic #201502110759 SMP Wed Feb 11
08:01:01 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
root@ProLiant:/mnt/backup/bug# btrfs send /bak/Portege/2014-06-01 |
btrfs rec -v .
At subvol /bak/Portege/2014-06-01
At subvol 2014-06-01
receiving subvol 2014-06-01 uuid=f80254c5-2f5a-b043-ad3e-e12287f7b7e8,
stransid=105481
BTRFS_IOC_SET_RECEIVED_SUBVOL
uuid=f80254c5-2f5a-b043-ad3e-e12287f7b7e8, stransid=105481
root@ProLiant:/mnt/backup/bug# btrfs send -p /bak/Portege/2014-06-01
/bak/Portege/2014-12-01_01-02-44 | btrfs rec -vvvv .
At subvol /bak/Portege/2014-12-01_01-02-44
At snapshot 2014-12-01_01-02-44
receiving snapshot 2014-12-01_01-02-44
uuid=b277e2ab-f0af-1e46-a8a3-cd587fd64a53, ctransid=474567
parent_uuid=f80254c5-2f5a-b043-ad3e-e12287f7b7e8,
parent_ctransid=105481
utimes
rename .duplicity -> o257-9667-0
mkdir o257-473948-0
rename o257-473948-0 -> .duplicity
utimes
chown .duplicity - uid=0, gid=100
chmod .duplicity - mode=02775
utimes .duplicity
rename .ecryptfs -> o258-9667-0
mkdir o258-473948-0
rename o258-473948-0 -> lost+found
utimes
chown lost+found - uid=0, gid=0
chmod lost+found - mode=0700
utimes lost+found
rmdir lost+found
mkdir o259-473948-0
rename o259-473948-0 -> monitor
ERROR: rename o259-473948-0 -> monitor failed. Directory not empty
-- Ames

Re: Receive "directory not empty" bug

[Filipe David Manana]

On Sat, Feb 28, 2015 at 2:05 AM, Ames Cornish <ames@cornishes.net> wrote:
> Hi,
>
> btrfs is consistently refusing to receive send of certain directories.
> It fails with the message "Directory not empty" for an internal
> directory on the receiving side.  Any ideas on what this might be or
> how to troubleshoot it?
>
> Here's an example:
>
> btrfs-progs v3.19-rc2
> root@ProLiant:/mnt/backup/bug# uname -a
> Linux ProLiant 3.18.7-031807-generic #201502110759 SMP Wed Feb 11
> 08:01:01 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> root@ProLiant:/mnt/backup/bug# btrfs send /bak/Portege/2014-06-01 |
> btrfs rec -v .
> At subvol /bak/Portege/2014-06-01
> At subvol 2014-06-01
> receiving subvol 2014-06-01 uuid=f80254c5-2f5a-b043-ad3e-e12287f7b7e8,
> stransid=105481
> BTRFS_IOC_SET_RECEIVED_SUBVOL
> uuid=f80254c5-2f5a-b043-ad3e-e12287f7b7e8, stransid=105481
> root@ProLiant:/mnt/backup/bug# btrfs send -p /bak/Portege/2014-06-01
> /bak/Portege/2014-12-01_01-02-44 | btrfs rec -vvvv .
> At subvol /bak/Portege/2014-12-01_01-02-44
> At snapshot 2014-12-01_01-02-44
> receiving snapshot 2014-12-01_01-02-44
> uuid=b277e2ab-f0af-1e46-a8a3-cd587fd64a53, ctransid=474567
> parent_uuid=f80254c5-2f5a-b043-ad3e-e12287f7b7e8,
> parent_ctransid=105481
> utimes
> rename .duplicity -> o257-9667-0
> mkdir o257-473948-0
> rename o257-473948-0 -> .duplicity
> utimes
> chown .duplicity - uid=0, gid=100
> chmod .duplicity - mode=02775
> utimes .duplicity
> rename .ecryptfs -> o258-9667-0
> mkdir o258-473948-0
> rename o258-473948-0 -> lost+found
> utimes
> chown lost+found - uid=0, gid=0
> chmod lost+found - mode=0700
> utimes lost+found
> rmdir lost+found
> mkdir o259-473948-0
> rename o259-473948-0 -> monitor
> ERROR: rename o259-473948-0 -> monitor failed. Directory not empty
> -- Ames

Hi,

Can you please send the output of the following commands:

tree --inodes -d /bak/Portege/2014-06-01
tree --inodes -d /bak/Portege/2014-12-01_01-02-44

That should give me enough information to reproduce and fix it.

thanks

> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

Re: Receive "directory not empty" bug

[Ames Cornish]

Sending tree data directly to Filipe, due to size and confidentiality...

Thanks!

-- Ames

Re: Receive "directory not empty" bug

[Filipe David Manana]

On Sat, Feb 28, 2015 at 7:37 PM, Ames Cornish <ames@cornishes.net> wrote:
> Sending tree data directly to Filipe, due to size and confidentiality...

Thanks Ames.

In the meanwhile I noticed one similar problem with directory renames
and fixed it. I've just sent the patch to the list:

https://patchwork.kernel.org/patch/5906231/

It's likely to fix your issue, even though a quick glance at your logs
seems it can be a slightly different case.

Let me know if it fixes your case.

thanks

>
> Thanks!
>
> -- Ames
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."