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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org