Mailinglist Archive: opensuse (686 mails)

< Previous Next >
Re: [opensuse] Expand user's encrypted home image file
On Saturday, July 27, 2013 04:32:22 PM Jan Ritzerfeld wrote:
Am Samstag, 27. Juli 2013, 14:56:07 schrieb Marco Vittorini Orgeas:
[...]
At this point I guess I would be more lucky if I cross post this to the
dev mailing list, hoping someone there could shed some light over the
issue?

Okay, I looked at the source code myself, starting at line 499:
https://github.com/yast/yast-users/blob/master/src/UsersRoutines.pm
YaST simply calls cryptconfig with the enlarge-image option that enlarges
the disk image and the file system. Fine, reading the source code of
cryptconfig, I see that the enlarge-image option enlarges the image by
simply adding a single 0 byte at the new(!) end position effectively
creating a sparse file. Then it checks and resizes the filesystem using
resize2fs for ext* or resize_reiserfs for reiserfs.

So, I think that the enlargement done by YaST will increase the used space
by 1 byte during the whole process and in the end. Maybe resize2fs will need
some additional space.

However, try on your own risk!

Gruß
Jan

Thank You!
I had the time to make some tests in a virtualized environment and those are
the results:

| Before resizing
| ===============
| File: ‘/home/test.img’
| Size: 104857601 Blocks: 15728 IO Block: 4096 regular file
| Device: 802h/2050d Inode: 278951 Links: 1
| Access: (0600/-rw-------) Uid: ( 1001/ test) Gid: ( 0/ root)
| Access: 2013-07-27 23:45:45.424951970 +0200
| Modify: 2013-07-27 23:45:45.418951967 +0200
| Change: 2013-07-27 23:45:45.418951967 +0200
| Birth: -
|
| After expansion
| ===============
| File: ‘/home/test.img’
| Size: 209715202 Blocks: 21688 IO Block: 4096 regular file
| Device: 802h/2050d Inode: 278951 Links: 1
| Access: (0600/-rw-------) Uid: ( 1001/ test) Gid: ( 0/ root)
| Access: 2013-07-27 23:55:27.061452340 +0200
| Modify: 2013-07-27 23:55:27.051452341 +0200
| Change: 2013-07-27 23:55:27.051452341 +0200
| Birth: -
|
| After shrinking
| ===============
| File: ‘/home/test.img’
| Size: 209715202 Blocks: 21688 IO Block: 4096 regular file
| Device: 802h/2050d Inode: 278951 Links: 1
| Access: (0600/-rw-------) Uid: ( 1001/ test) Gid: ( 0/ root)
| Access: 2013-07-27 23:55:27.061452340 +0200
| Modify: 2013-07-27 23:55:27.051452341 +0200
| Change: 2013-07-27 23:55:27.051452341 +0200
| Birth: -

I feel confident to state that after the expansion, as you can see, the
i-node is the same, so the file is still the old one.

However, after a bit of gymnastic with "strace" I also have isolated
the related syscalls (the size are different in respect to the previous
output because I needed to fine tune strace and I had to kept expanding the
file with yast):

| mmap2(NULL, 26242, PROT_READ, MAP_SHARED, 3, 0) = 0xb7031000
| close(3) = 0
| futex(0xb72d3fc8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
| access("/home/test.img", F_OK) = 0
| open("/home/test.img", O_WRONLY|O_LARGEFILE) = 3
| flock(3, LOCK_EX) = 0
| _llseek(3, 10485760, [272629763], SEEK_END) = 0
| write(3, "\0", 1) = 1
| close(3) = 0
| access("/dev/mapper/_home_test.img", F_OK) = 0
| write(2, "The map device for this image is"..., 40) = 40

This confirm yast "stretches" the file size by writing that '\0' at the new
position (old size + increase).
I am not sure if this automatically create a sparse file because:
1. The file originally is not created as such.
2. Effectively the file size is reported by (according to 'ls') counting
also the padded zeros bytes, before and after the re-sizing.
The choice to not create a sparse file could be questionable
- https://en.wikipedia.org/wiki/Sparse_file - but seen the nature of the file
(the home directory!) it could be that devs have chosen *not* to run any
risks?

The resize2fs stage should not create "space" problems (or at least not big
problems).In fact, accordingly to
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/resize/resize2fs.c

| /*
| * Resizing a filesystem consists of the following phases:
| *
| * 1. Adjust superblock and write out new parts of the inode
| * table
| * 2. Determine blocks which need to be relocated, and copy the
| * contents of blocks from their old locations to the new ones.
| * 3. Scan the inode table, doing the following:
| * a. If blocks have been moved, update the block
| * pointers in the inodes and indirect blocks to
| * point at the new block locations.
| * b. If parts of the inode table need to be evacuated,
| * copy inodes from their old locations to their
| * new ones.
| * c. If (b) needs to be done, note which blocks contain
| * directory information, since we will need to
| * update the directory information.
| * 4. Update the directory blocks with the new inode locations.
| * 5. Move the inode tables, if necessary.
| */
|
Apart from 2, to me it seems like the bulk of the work is done over the
i-node table.

Some comments:
The Yast gui/cli interface is broken: in both I can slide the home size
upwards *and* downwards.*But* while a bigger size is honoured by effectively
enlarging the file, a smaller size is perfectly ignored: that is confirmed by
looking at that "sub CryptHome" in
https://github.com/yast/yast-users/blob/master/src/UsersRoutines.pm which
ignores the case where $org_size > $home_size.
You don't get any warnings that it won't succeed and Yast even give the
impression to actually processing the request.
The "stat" output confirm this.

I wonder why should be ignored such a thing?Creating a smaller image file and
copying in the old content is quite linear, on the lines of how Yast
already manages an image file "decryption" request, line 360
https://github.com/yast/yast-users/blob/master/src/UsersRoutines.pm.
If implemented, this could represent a big advantage over the "Ubuntu"
ecrypt-fs approach which deal directly with partitions and would actually
make justice to the image file approach!

Remain the fact that at the moment that slide shouldn't allow to go downwards!
Maybe a related bug issue should be open.

I will proceed with the actual re-sizing as soon I will have a backup and
will post the result here.
--
Marco
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >