On 8/28/13 10:29 AM, Tim wrote: > Hi, > > I used resize2fs to do an online grow of from 8TB to 12TB and that worked fine. > now I'm trying to offline shrink back down to 8TB and resize2fs is > unable to do so. > > Output: > resize2fs -M /dev/mapper/ > crypt_left > resize2fs 1.42.5 (29-Jul-2012) > Resizing the filesystem on /dev/mapper/crypt_left to 1885633106 (4k) blocks. > resize2fs: Memory allocation failed while trying to resize > /dev/mapper/crypt_left > Please run 'e2fsck -fy /dev/mapper/crypt_left' to fix the filesystem > after the aborted resize operation. > > I am using a raspberrypi so it's 32-bit and limited to 256MB and I > have 2x that in swap. Ok, now, hold on right there ;) On the one hand it's worth understanding which memory allocation failed and whether there's anything to be done about it, but: Hoping to administer a 12T filesystem on a box with 256M of memory is almost certainly wishful thinking. (ok, 768M with swap) A crucial part of deploying systems with very large filesystems is ensuring that there is enough system memory to go along with it; in this case, there almost certainly is not. > uname -a > Linux test 3.6.11+ #474 PREEMPT Thu Jun 13 17:14:42 BST 2013 armv6l GNU/Linux > > I was watching top and never saw it use more that 53% of the RAM but I > may have missed the crucial moment. > (taken during a "e2fsck -fy ") > free > total used free shared buffers cached > Mem: 237648 225440 12208 0 63240 11796 > -/+ buffers/cache: 150404 87244 > Swap: 475132 13444 461688 > > Please let me know if there is anything that would help solve this issue. You might use gdb, or an instrumented resize2fs, to find out which memory allocation is failing and/or where the memory allocations are going. The sad truth may just be that 256M + 512M swap isn't going to do the trick. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
