fixed size disks cannot be created in encrypted home dir

[iluetkeb]

My home dir is encryped using the default method of Ubuntu Lucid Lynx (10.04). Creating a fixed size hard-disk in ~/.VirtualBox fails, with VBoxSVC consuming 99% CPU.

Creating the hard-disk outside of the home works.

[Klaus Espenlaub]

What's the error message? Or does it simply take (almost) forever?

[iluetkeb]

There is no error message -- the progress simply hangs at 0% forever and it consumes 99% CPU. I have left it like that over lunch (about an hour) and no change whatsoever. As soon as I configured it to create the disk on /var/tmp, it took about 5 minutes to create the disk.

[aeichner]

Can you please post the complete command you use to create the fixed image? I just tried it here with VDI, VMDK and VHD and it works as expected.

[iluetkeb]

I used the virtualbox manager (GUI) and created a VDI image with 4 or 8GB fixed size.

[aeichner]

Thanks for the additional information. Unfortunately I still can't reproduce the problem. Tried 4G and 8G images. The 8G needs some time and VBoxSVC consumes quite a bit of CPU but I think that is expected because the image needs to be encrypted.

[Brad Edmondson]

I can reproduce this issue with vbox 3.2.8 OSE in ubuntu 10.10 i368. The issue appears with VBoxSVC taking 100% of cpu and refusing to die with 'kill -s 9' but the named file (though created) stays at a size 0 bytes. htop shows the cpu usage, but reports no IO-write calls from virtualbox or vboxsvc. There don't appear to be any log messages relating to this event, but I could just be missing them.

My homedir is encrypted using the stock ubuntu homedir encryption scheme (ecryptefs, mounted on login).

I am eager to provide any further information that may help track down this bug.

[Frank Mehnert]

An interesting information could be an strace. Please do the following (make sure no VBoxSVC daemon is running at this time):

/usr/bin/strace -o ~/log -s128 -f /usr/lib/virtualbox/VBoxSVC

Now try to create the fixed sized disk. After waiting for some time, abort the operation, compress the resulting log file ~/log and attach it to this ticket.

[Brad Edmondson]

1 of 3: requested strace on vboxsvc. command: "vboxmanage createhd --filename fedora14.vdi --size 11000 --variant fixed"

[Brad Edmondson]

2 of 3: requested strace on vboxsvc. command: "vboxmanage createhd --filename fedora14.vdi --size 11000 --variant fixed"

[Brad Edmondson]

3 of 3: requested strace on vboxsvc. command: "vboxmanage createhd --filename fedora14.vdi --size 11000 --variant fixed"

[Brad Edmondson]

Requested strace have been attached in 7zip format; original was 23mb and compressed only to 550k at best. 7z allowed for easy splitting into files small enough to attach in trac (size limit is 400k?).

Please let me know if I can provide anything further.

[Frank Mehnert]

Thanks. Analyzing the log file shows that

ftruncate64(11, 11534380544 <unfinished ...>

never returns. I wonder if this system call is not allowed on a compressed partition.

[Brad Edmondson]

I can confirm that on stock ubuntu 10.04 I was able to successfully create fixed-size VDIs within an encrypted partition (so virtualbox-ose_3.1.6-dfsg-2ubuntu2) using the GUI (which I assume called vboxsvc, though I am not positive. The VDIs were not split into 2gb chunks, so is it likely that ftruncate64() was in use at that time?

I am not familiar enough with syscalls to know where ftruncate64 is defined or where to file the bug if it is in ecryptfs. If this vbox bug will be closed can you assist me in routing it upstream?

Thanks, Brad

[Frank Mehnert]

The reason for using ftruncate(64) is that the file system usually can use an optimized if a file only needs to be enlarged or shortened without changing the data. On a normal file system, ftruncate should only take some seconds or less to enlarge a file. Of course this can take much longer on a compressed file system and it would be indeed interesting to see if the operation will finally terminate after waiting a resonable amount of time (several minutes).

[iluetkeb]

As mentioned in my second comment, I left the creation running for about an hour, without any change.

[Frank Mehnert]

But then this really sounds like a kernel bug ... Could you test a small test application?

#define _FILE_OFFSET_BITS 64
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main(void)
{
    int fd = open("foo123", O_CREAT|O_RDWR|O_EXCL, 0777);
    int err;
    if (fd < 0)
    {
        perror("open");
        return 1;
    }
    err = ftruncate(fd, 11534380544ULL);
    if (err < 0)
    {
        perror("ftruncate");
        return 1;
    }
    close(fd);
    return 0;
}

Compile it with

gcc -o foobar -O2 foobar.c

Then execute it on the compressed partition. Does it return immediately or how long does it take?

[iluetkeb]

The example took 1 minute and 44 seconds on my machine, on an /encrypted/ partition. That test was run on an SSD, so it would probably take much longer on a regular disk (the original issue was on a regular disk).

btw, during that time, the process couldn't be killed by any means and a large amount of data was written to the disk.

[Frank Mehnert]

So it would be interesting how VBox creating a fixed virtual disk on this SSD would perform.

[aeichner]

Closing, please reopen if still relevant.