256MB? Cough, choke. Yeah, I'm not at __all__ surprised that resize2fs required more memory than that.
In fact, there will be certain sorts of file system corruption or certain file system patterns (i.e., using lots and lots of hard links), where it's almost certain that 256MB, or even 512MB, won't be enough memory for e2fsck to repair a corrupted file system in some cases. (E2fsck was architected to trade memory usage for run time, on the assumption that most of the time, when you have a large file system, you also have adequate amounts of memory, and people would prefer that fsck run as quickly as possible, especially when during boot there is no other use for the memory. I've done some work so that e2fsck could work well on a system with only 4GB of memory, and two dozen 2TB disks each mounted as a separate file system, so the latest versions of e2fsprogs are a bit better about optimizing memory usage. But note that I'm talking about gigabytes of memory, not megabytes....) With a 32-bit system, userspace is limited to 3GB of virtual address space, which is why I asked the question --- on x86 with PAE, you can have a 32-bit system with 32GB of memory, but a single process won't be able to use more than 3GB of that memory. But if this is a system with only 256MB of memory, that's not going to be the limit; the limiting factor will be your physical memory and your swap. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/455024 Title: resize2fs: memory allocation failed while trying to resize To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/455024/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
