ecryptfs_write_metadata: Error writing metadata out to lower file; rc = [-13]

DISCUSSION Martin Steigerwald 3 participants 6 messages Dec 19, 2011 – Dec 20, 2011 Ecrypt file system

Share & tools

Martin Steigerwald

author

2011-12-19 12:33 UTC #0 lore raw

Hi!

Today I tested again whether ecryptfs would be suitable to replace encfs on my laptop. But I found several problems. The blocking one is:

ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning#2> LANG=C make […]
sed: couldn't open temporary file ./sedhqlAcd: Permission denied […]

ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> LANG=C ls -l | tail -6
ls: cannot access sedhqlAcd: No such file or directory
ls: cannot access sedChky0a: No such file or directory
ls: cannot access sed1eW8Ek: No such file or directory
ls: cannot access sedEjR2oA: No such file or directory
ls: cannot access sedb4JEiI: No such file or directory
ls: cannot access sedy0KQnt: No such file or directory

-?????????  ? ?  ?            ?            ? sedChky0a
-?????????  ? ?  ?            ?            ? sedEjR2oA
----------  1 ms teamix 1143445 Dec  5 10:01 sedNL1bTk
-?????????  ? ?  ?            ?            ? sedb4JEiI
-?????????  ? ?  ?            ?            ? sedhqlAcd
-?????????  ? ?  ?            ?            ? sedy0KQnt

Output in dmesg is:

ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> sudo tail -2 /var/log/syslog

Dec 19 13:23:30 merkaba kernel: [50999.570071] ecryptfs_write_metadata: Error 
writing metadata out to lower file; rc = [-13]
Dec 19 13:23:30 merkaba kernel: [50999.570083] Error writing headers; rc =

[-13]

Ecryptfs is configured as follows:

merkaba:~> cat .ecryptfsrc
ecryptfs_unlink_sigs
ecryptfs_sig=[…]
ecryptfs_fnek_sig=[…]
ecryptfs_xattr
ecryptfs_key_bytes=32
ecryptfs_cipher=aes
ecryptfs_passthrough=n

I am using extended attributes to avoid the space waste of 8 KiB per file.

The underlying filesystem is:

merkaba:~> grep /home /proc/mounts
/dev/mapper/merkaba-home /home ext4
rw,noatime,user_xattr,acl,barrier=1,stripe=128,data=ordered 0 0
/home/.ms /home/ms ecryptfs rw,relatime,ecryptfs_fnek_sig=[…],ecryptfs_sig=[…],ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_xattr_metadata,ecryptfs_unlink_sigs 0 0

Kernel is:

ms@merkaba:~> cat /proc/version
Linux version 3.2.0-rc4-amd64 (Debian 3.2~rc4-1~experimental.1) ([email protected]) (gcc version 4.6.2 (Debian 4.6.2-5) ) #1 SMP Sun Dec 4 18:38:24 UTC 2011

With encfs or from my local workstation via NFS there is no such issue.

Ciao,

Signature · 2 lines

Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

Tyler Hicks

2011-12-20 01:06 UTC #1 lore raw

Quoted 4 lines · Martin Steigerwald

Hi!
Today I tested again whether ecryptfs would be suitable to replace encfs on my laptop. But I found several problems. The blocking one is:

Sorry, hopefully we can get them straightened out.

Quoted 43 lines

ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning#2> LANG=C make […]
sed: couldn't open temporary file ./sedhqlAcd: Permission denied […]
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> LANG=C ls -l | tail -6
ls: cannot access sedhqlAcd: No such file or directory
ls: cannot access sedChky0a: No such file or directory
ls: cannot access sed1eW8Ek: No such file or directory
ls: cannot access sedEjR2oA: No such file or directory
ls: cannot access sedb4JEiI: No such file or directory
ls: cannot access sedy0KQnt: No such file or directory
-?????????  ? ?  ?            ?            ? sedChky0a
-?????????  ? ?  ?            ?            ? sedEjR2oA
----------  1 ms teamix 1143445 Dec  5 10:01 sedNL1bTk
-?????????  ? ?  ?            ?            ? sedb4JEiI
-?????????  ? ?  ?            ?            ? sedhqlAcd
-?????????  ? ?  ?            ?            ? sedy0KQnt
Output in dmesg is:
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> sudo tail -2 /var/log/syslog
Dec 19 13:23:30 merkaba kernel: [50999.570071] ecryptfs_write_metadata: Error 
writing metadata out to lower file; rc = [-13]
Dec 19 13:23:30 merkaba kernel: [50999.570083] Error writing headers; rc = 
[-13]
Ecryptfs is configured as follows:
merkaba:~> cat .ecryptfsrc
ecryptfs_unlink_sigs
ecryptfs_sig=[…]
ecryptfs_fnek_sig=[…]
ecryptfs_xattr
ecryptfs_key_bytes=32
ecryptfs_cipher=aes
ecryptfs_passthrough=n

Quoted 1 line

I am using extended attributes to avoid the space waste of 8 KiB per file.

I must warn you that the ecryptfs_xattr_metadata option is rarely used by anyone and gets little testing from me upstream. I understand the desire to save some space, but you should also consider stability here. I'm working to automate some of that testing soon, so there is hope that things could get better in this area.

Quoted 10 lines

The underlying filesystem is:
merkaba:~> grep /home /proc/mounts
/dev/mapper/merkaba-home /home ext4
rw,noatime,user_xattr,acl,barrier=1,stripe=128,data=ordered 0 0
/home/.ms /home/ms ecryptfs rw,relatime,ecryptfs_fnek_sig=[…],ecryptfs_sig=[…],ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_xattr_metadata,ecryptfs_unlink_sigs 0 0

Quoted 4 lines

Kernel is:
ms@merkaba:~> cat /proc/version
Linux version 3.2.0-rc4-amd64 (Debian 3.2~rc4-1~experimental.1)

Ok, I was able to reproduce this on roughly the same kernel version by untar'ing the kernel source.

I'll have to do some more investigation into how we can handle this error better. ext4 is returning an error when we're trying to create the xattr upon file creation, so how we convey that to userspace through the creat() return value and how we clean up after ourselves is probably the issue here.

Tyler

Quoted 14 lines

([email protected]) (gcc version 4.6.2 (Debian 4.6.2-5) ) #1 SMP Sun Dec 4 18:38:24 UTC 2011
With encfs or from my local workstation via NFS there is no such issue.
Ciao,
Signature · 6 lines
Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Martin Steigerwald

author

2011-12-20 08:46 UTC #2 lore raw

Am Dienstag, 20. Dezember 2011 schrieb Tyler Hicks:

Quoted 8 lines · Martin Steigerwald

Quoted 6 lines
Hi!
Today I tested again whether ecryptfs would be suitable to replace encfs on my
laptop. But I found several problems. The blocking one is:
Sorry, hopefully we can get them straightened out.

Thanks for taking care.

There is no hurry. Encfs basically works reliably. Only thing is, that it is slow at times and tends to use quite a bit of CPU time even on this ThinkPad T520 with Intel Sandybridge i5 and Intel SSD 320. I hope that this will be better with ecryptfs.

Quoted 42 lines

Quoted 42 lines
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning#2> LANG=C make […]
sed: couldn't open temporary file ./sedhqlAcd: Permission denied […]
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> LANG=C ls -l | tail -6
ls: cannot access sedhqlAcd: No such file or directory
ls: cannot access sedChky0a: No such file or directory
ls: cannot access sed1eW8Ek: No such file or directory
ls: cannot access sedEjR2oA: No such file or directory
ls: cannot access sedb4JEiI: No such file or directory
ls: cannot access sedy0KQnt: No such file or directory
-?????????  ? ?  ?            ?            ? sedChky0a
-?????????  ? ?  ?            ?            ? sedEjR2oA
----------  1 ms teamix 1143445 Dec  5 10:01 sedNL1bTk
-?????????  ? ?  ?            ?            ? sedb4JEiI
-?????????  ? ?  ?            ?            ? sedhqlAcd
-?????????  ? ?  ?            ?            ? sedy0KQnt
Output in dmesg is:
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> sudo tail -2 /var/log/syslog
Dec 19 13:23:30 merkaba kernel: [50999.570071] ecryptfs_write_metadata:
Error writing metadata out to lower file; rc = [-13]
Dec 19 13:23:30 merkaba kernel: [50999.570083] Error writing headers; rc
= [-13]
Ecryptfs is configured as follows:
merkaba:~> cat .ecryptfsrc
ecryptfs_unlink_sigs
ecryptfs_sig=[…]
ecryptfs_fnek_sig=[…]
ecryptfs_xattr
ecryptfs_key_bytes=32
ecryptfs_cipher=aes
ecryptfs_passthrough=n

Quoted 8 lines

Quoted 2 lines
I am using extended attributes to avoid the space waste of 8 KiB per file.
I must warn you that the ecryptfs_xattr_metadata option is rarely used by anyone and gets little testing from me upstream. I understand the desire to save some space, but you should also consider stability here. I'm working to automate some of that testing soon, so there is hope that things could get better in this area.

Okay. Thanks for the warning.

Why is that? Obviously it seems to me that xattr has quite some advantages? I find 8 KiB per file quite some space waste. Rsync can copy xattrs so backup is possible. But then the directory I want to encrypt is only about 63600 files. That would make 508800 KiB. Well even that is about half an GiB. Well could be acceptable for now since its at least an 300 GB SSD.

But does it also mean more writes? Not that it should matter much. Might make sense to test it this way anyway. When I understand it correctly, this error should not happen then. I think I will try it.

My other home directory has about 852550 files and there about 3,25 GiB would be wasted. Too good that I do not plan to encrypt it right now. ;)

Do you now about xfstests test suite? Maybe a suitable sub selection of tests in there could help with testing ecryptfs.

Quoted 14 lines

Quoted 9 lines
The underlying filesystem is:
merkaba:~> grep /home /proc/mounts
/dev/mapper/merkaba-home /home ext4 rw,noatime,user_xattr,acl,barrier=1,stripe=128,data=ordered 0 0 /home/.ms /home/ms ecryptfs rw,relatime,ecryptfs_fnek_sig=[…],ecryptfs_sig=[…],ecryptfs_cipher=aes,ec ryptfs_key_bytes=32,ecryptfs_xattr_metadata,ecryptfs_unlink_sigs 0 0
Quoted 4 lines
Kernel is:
ms@merkaba:~> cat /proc/version
Linux version 3.2.0-rc4-amd64 (Debian 3.2~rc4-1~experimental.1)

Quoted 8 lines

Ok, I was able to reproduce this on roughly the same kernel version by untar'ing the kernel source.
I'll have to do some more investigation into how we can handle this error better. ext4 is returning an error when we're trying to create the xattr upon file creation, so how we convey that to userspace through the creat() return value and how we clean up after ourselves is probably the issue here.

Why is Ext4 returning an error? Shouldn´t it just set the attribute and thats it? Maybe it has an issue doing it upon file creation? Could an Ext4 bug be involved here? I am willing to report with to Ext4 developers if need be.

Thanks,

Signature · 2 lines

Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

Martin Steigerwald

author

2011-12-20 09:45 UTC #3 lore raw

Am Dienstag, 20. Dezember 2011 schrieb Martin Steigerwald:

Quoted 71 lines

Quoted 57 lines
Quoted 52 lines
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning#2> LANG=C make […]
sed: couldn't open temporary file ./sedhqlAcd: Permission denied […]
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> LANG=C ls -l | tail -6
ls: cannot access sedhqlAcd: No such file or directory
ls: cannot access sedChky0a: No such file or directory
ls: cannot access sed1eW8Ek: No such file or directory
ls: cannot access sedEjR2oA: No such file or directory
ls: cannot access sedb4JEiI: No such file or directory
ls: cannot access sedy0KQnt: No such file or directory
-?????????  ? ?  ?            ?            ? sedChky0a
-?????????  ? ?  ?            ?            ? sedEjR2oA
----------  1 ms teamix 1143445 Dec  5 10:01 sedNL1bTk
-?????????  ? ?  ?            ?            ? sedb4JEiI
-?????????  ? ?  ?            ?            ? sedhqlAcd
-?????????  ? ?  ?            ?            ? sedy0KQnt
Output in dmesg is:
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> sudo tail -2 /var/log/syslog
Dec 19 13:23:30 merkaba kernel: [50999.570071] ecryptfs_write_metadata:
Error writing metadata out to lower file; rc = [-13]
Dec 19 13:23:30 merkaba kernel: [50999.570083] Error writing headers;
rc = [-13]
Ecryptfs is configured as follows:
merkaba:~> cat .ecryptfsrc
ecryptfs_unlink_sigs
ecryptfs_sig=[…]
ecryptfs_fnek_sig=[…]
ecryptfs_xattr
ecryptfs_key_bytes=32
ecryptfs_cipher=aes
ecryptfs_passthrough=n
Quoted 2 lines
I am using extended attributes to avoid the space waste of 8 KiB per file.
Quoted 5 lines
I must warn you that the ecryptfs_xattr_metadata option is rarely used by anyone and gets little testing from me upstream. I understand the desire to save some space, but you should also consider stability here. I'm working to automate some of that testing soon, so there is hope that things could get better in this area.
Okay. Thanks for the warning.
Why is that? Obviously it seems to me that xattr has quite some advantages? I find 8 KiB per file quite some space waste. Rsync can copy xattrs so backup is possible. But then the directory I want to encrypt is only about 63600 files. That would make 508800 KiB. Well even that is about half an GiB. Well could be acceptable for now since its at least an 300 GB SSD.

Quoted 3 lines

But does it also mean more writes? Not that it should matter much. Might make sense to test it this way anyway. When I understand it correctly, this error should not happen then. I think I will try it.

Okay, I now tried without putting metadata in extended attributes.

This works. Above issue didn´t show up.

Space waste is approximately as estimated:

merkaba:~> du -s /home/ms
13672464 /home/ms
merkaba:~> du -s /home/ms2
13155688 /home/ms2

And generating slides for my linux trainings has become a *whole lot* faster. I didn't expect such a kind of performance improvement - more than twice as fast:

encfs:

ms@merkaba:/home/ms2/Training/TXS-svn/Linux_15_Performance_Tuning> /usr/bin/time -v make
[…]
Command being timed: "make"
User time (seconds): 40.25
System time (seconds): 4.41
Percent of CPU this job got: 87%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:51.01 Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1162240 Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 68
Minor (reclaiming a frame) page faults: 219219 Voluntary context switches: 428959
Involuntary context switches: 14977
Swaps: 0
File system inputs: 179032
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

ecryptfs:

ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> /usr/bin/time -v make
[…]
Command being timed: "make"
User time (seconds): 42.11
System time (seconds): 1.39
Percent of CPU this job got: 191%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:22.70 Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1221664
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 162
Minor (reclaiming a frame) page faults: 238379 Voluntary context switches: 7180
Involuntary context switches: 13078
Swaps: 0
File system inputs: 195680
File system outputs: 64032
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

Thanks,

Signature · 2 lines

Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

Alexis Hafner

2011-12-20 12:05 UTC #4 lore raw

In reply to Tyler Hicks

Hi Tyler,

I can report the same bug on a 64-bits Rhel server 6.2 machine running the default Red Hat kernel, also with ext4 as the lower file-system :
using extended attributes fails with the same error logs. This could indicate that the problem is not limited to the last development kernels, but has been here a little longer.

Alexis

Quoted 99 lines · Tyler Hicks

Quoted 4 lines · Martin Steigerwald
Hi!
Today I tested again whether ecryptfs would be suitable to replace encfs on my laptop. But I found several problems. The blocking one is:
Sorry, hopefully we can get them straightened out.
Quoted 43 lines
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning#2> LANG=C make […]
sed: couldn't open temporary file ./sedhqlAcd: Permission denied […]
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> LANG=C ls -l | tail -6
ls: cannot access sedhqlAcd: No such file or directory
ls: cannot access sedChky0a: No such file or directory
ls: cannot access sed1eW8Ek: No such file or directory
ls: cannot access sedEjR2oA: No such file or directory
ls: cannot access sedb4JEiI: No such file or directory
ls: cannot access sedy0KQnt: No such file or directory
-?????????  ? ?  ?            ?            ? sedChky0a
-?????????  ? ?  ?            ?            ? sedEjR2oA
----------  1 ms teamix 1143445 Dec  5 10:01 sedNL1bTk
-?????????  ? ?  ?            ?            ? sedb4JEiI
-?????????  ? ?  ?            ?            ? sedhqlAcd
-?????????  ? ?  ?            ?            ? sedy0KQnt
Output in dmesg is:
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> sudo tail -2 /var/log/syslog
Dec 19 13:23:30 merkaba kernel: [50999.570071] ecryptfs_write_metadata: Error
writing metadata out to lower file; rc = [-13]
Dec 19 13:23:30 merkaba kernel: [50999.570083] Error writing headers; rc =
[-13]
Ecryptfs is configured as follows:
merkaba:~> cat .ecryptfsrc
ecryptfs_unlink_sigs
ecryptfs_sig=[…]
ecryptfs_fnek_sig=[…]
ecryptfs_xattr
ecryptfs_key_bytes=32
ecryptfs_cipher=aes
ecryptfs_passthrough=n
Quoted 1 line
I am using extended attributes to avoid the space waste of 8 KiB per file.
I must warn you that the ecryptfs_xattr_metadata option is rarely used by anyone and gets little testing from me upstream. I understand the desire to save some space, but you should also consider stability here. I'm working to automate some of that testing soon, so there is hope that things could get better in this area.
Quoted 10 lines
The underlying filesystem is:
merkaba:~> grep /home /proc/mounts
/dev/mapper/merkaba-home /home ext4
rw,noatime,user_xattr,acl,barrier=1,stripe=128,data=ordered 0 0
/home/.ms /home/ms ecryptfs rw,relatime,ecryptfs_fnek_sig=[…],ecryptfs_sig=[…],ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_xattr_metadata,ecryptfs_unlink_sigs 0 0
Quoted 4 lines
Kernel is:
ms@merkaba:~> cat /proc/version
Linux version 3.2.0-rc4-amd64 (Debian 3.2~rc4-1~experimental.1)
Ok, I was able to reproduce this on roughly the same kernel version by untar'ing the kernel source.
I'll have to do some more investigation into how we can handle this error better. ext4 is returning an error when we're trying to create the xattr upon file creation, so how we convey that to userspace through the creat() return value and how we clean up after ourselves is probably the issue here.
Tyler
Quoted 14 lines
([email protected]) (gcc version 4.6.2 (Debian 4.6.2-5) ) #1 SMP Sun Dec 4 18:38:24 UTC 2011
With encfs or from my local workstation via NFS there is no such issue.
Ciao,
--
Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Martin Steigerwald

author

2011-12-20 12:27 UTC #5 lore raw

Am Dienstag, 20. Dezember 2011 schrieb Alexis Hafner:

Quoted 60 lines · Tyler Hicks

Quoted 59 lines · Martin Steigerwald
Quoted 6 lines
Hi!
Today I tested again whether ecryptfs would be suitable to replace encfs on my
laptop. But I found several problems. The blocking one is:
Sorry, hopefully we can get them straightened out.
Quoted 42 lines
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning#2> LANG=C make […]
sed: couldn't open temporary file ./sedhqlAcd: Permission denied […]
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> LANG=C ls -l | tail -6
ls: cannot access sedhqlAcd: No such file or directory
ls: cannot access sedChky0a: No such file or directory
ls: cannot access sed1eW8Ek: No such file or directory
ls: cannot access sedEjR2oA: No such file or directory
ls: cannot access sedb4JEiI: No such file or directory
ls: cannot access sedy0KQnt: No such file or directory
-?????????  ? ?  ?            ?            ? sedChky0a
-?????????  ? ?  ?            ?            ? sedEjR2oA
----------  1 ms teamix 1143445 Dec  5 10:01 sedNL1bTk
-?????????  ? ?  ?            ?            ? sedb4JEiI
-?????????  ? ?  ?            ?            ? sedhqlAcd
-?????????  ? ?  ?            ?            ? sedy0KQnt
Output in dmesg is:
ms@merkaba:~/Training/TXS-svn/Linux_15_Performance_Tuning> sudo tail -2 /var/log/syslog
Dec 19 13:23:30 merkaba kernel: [50999.570071] ecryptfs_write_metadata:
Error writing metadata out to lower file; rc = [-13]
Dec 19 13:23:30 merkaba kernel: [50999.570083] Error writing headers; rc
= [-13]
Ecryptfs is configured as follows:
merkaba:~> cat .ecryptfsrc
ecryptfs_unlink_sigs
ecryptfs_sig=[…]
ecryptfs_fnek_sig=[…]
ecryptfs_xattr
ecryptfs_key_bytes=32
ecryptfs_cipher=aes
ecryptfs_passthrough=n
Quoted 2 lines
I am using extended attributes to avoid the space waste of 8 KiB per file.
I must warn you that the ecryptfs_xattr_metadata option is rarely used by anyone and gets little testing from me upstream. I understand the desire to save some space, but you should also consider stability here. I'm working to automate some of that testing soon, so there is hope that things could get better in this area.

[…]

Quoted 5 lines

I can report the same bug on a 64-bits Rhel server 6.2 machine running the default Red Hat kernel, also with ext4 as the lower file-system :
using extended attributes fails with the same error logs. This could indicate that the problem is not limited to the last development kernels, but has been here a little longer.

Can you also reproduce the rsync copies twice issue I reported in the other thread? Does the bug disappear when storing metadata in files instead.

Would be nice to have confirmation for that as well.

Thanks,

Signature · 2 lines

Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90