From michael at mayer.cx  Wed Nov  4 15:05:59 2009
From: michael at mayer.cx (Michael Mayer)
Date: Wed, 4 Nov 2009 21:05:59 +0100 (CET)
Subject: [Unionfs] unionfs 2.5.3 and NFS / tmpfs
Message-ID: <alpine.LFD.2.00.0911042043540.9633@deepsky.mayer.cx>

Hi all,

I am playing around with unionfs-2.5.3 under CentOS 5.4 with a 
patched kernel based on 2.6.18-164.el5.

My branches consist of a read-only NFS mount of the root-fs and a 
read-write overlay using tmpfs.

Everything works great. I can create/modify/delete files, everything 
appears to be ok.

There is a little catch however. In some access modes, files get created 
as empty files and no content can be written from the application.
I have noticed this behavior when compiling a kernel. Any compilation 
which writes onto the unionfs part fails.

stracing the problem unfortunately does not show any error status except 
the one straight from rpm:

....
open("/var/tmp/rpm-tmp.40386", O_RDWR|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 
0666) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
stat64("/var/tmp/rpm-tmp.40386", {st_mode=S_IFREG|0644, st_size=0, ...}) = 
0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
write(2, "error: ", 7)                  = 7
write(2, "error creating temporary file /var/tmp/rpm-tmp.40386\n", 53) = 
53
....

Tried to change the output directory but as long as it writes on unionfs 
it breaks. After the program stops, I can find a zero byte file in the 
respective directory.

if I copy a file (actually dd'ing log3 into log5, I get

....
stat64("log5", 0xbfbd55cc)              = -1 ENOENT (No such file or 
directory)
stat64("log3", {st_mode=S_IFREG|0664, st_size=1, ...}) = 0
stat64("log5", 0xbfbd5478)              = -1 ENOENT (No such file or 
directory)
open("log3", O_RDONLY|O_LARGEFILE)      = 3
fstat64(3, {st_mode=S_IFREG|0664, st_size=1, ...}) = 0
open("log5", O_WRONLY|O_CREAT|O_LARGEFILE, 0100664) = 4
fstat64(4, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0664, st_size=1, ...}) = 0
read(3, "\n", 4096)                     = 1
write(4, "\n", 1)                       = 1
read(3, "", 4096)                       = 0
close(4)                                = 0
close(3)                                = 0
....

I am slightly puzzled now because there is no error message from any of 
the syscalls and yet it fails.

The difference in the open statements are the use of O_TRUNC, O_EXCL and 
O_RDWR.

It vaguely looks to me as it was related to 
https://bugzilla.filesystems.org/show_bug.cgi?id=624

Does anyone see a similar behaviour with unionfs 2.5.3 ? Any thoughts on 
how this could be fixed ?

Cheers,

Michael.