VirtualBox

Ticket #6801 (closed defect: fixed)

Opened 4 years ago

Last modified 11 months ago

fixed size disks cannot be created in encrypted home dir

Reported by: iluetkeb Owned by:
Priority: major Component: virtual disk
Version: VirtualBox 3.2.0 Keywords: encryption
Cc: Guest type: Linux
Host type: Linux

Description (last modified by aeichner) (diff)

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.

Attachments

log.7z.001 Download (307.2 KB) - added by bradleee 3 years ago.
1 of 3: requested strace on vboxsvc. command: "vboxmanage createhd --filename fedora14.vdi --size 11000 --variant fixed"
log.7z.002 Download (307.2 KB) - added by bradleee 3 years ago.
2 of 3: requested strace on vboxsvc. command: "vboxmanage createhd --filename fedora14.vdi --size 11000 --variant fixed"
log.7z.003 Download (125.9 KB) - added by bradleee 3 years ago.
3 of 3: requested strace on vboxsvc. command: "vboxmanage createhd --filename fedora14.vdi --size 11000 --variant fixed"

Change History

comment:1 Changed 4 years ago by klaus

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

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by iluetkeb

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

comment:5 Changed 4 years ago by 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.

comment:6 Changed 3 years ago by bradleee

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.

comment:7 Changed 3 years ago by frank

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.

Changed 3 years ago by bradleee

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

Changed 3 years ago by bradleee

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

Changed 3 years ago by bradleee

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

comment:8 Changed 3 years ago by bradleee

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.

comment:9 Changed 3 years ago by frank

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.

comment:10 Changed 3 years ago by bradleee

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

comment:11 Changed 3 years ago by frank

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).

comment:12 Changed 3 years ago by iluetkeb

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

comment:13 Changed 3 years ago by frank

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?

comment:14 Changed 3 years ago by 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.

comment:15 Changed 3 years ago by frank

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

comment:16 Changed 11 months ago by aeichner

  • Status changed from new to closed
  • Resolution set to fixed
  • Description modified (diff)

Closing, please reopen if still relevant.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use