Hello,
On Tue, Jul 06, 2021 at 02:34:30PM +0300, IL Ka wrote:
> > I use a 32bit OS
Is the hardware capable of 64-bit? If so then it should be possible
to install an amd64 kernel and e2fsprogs without completely
converting your system to amd64.
https://wiki.debian.org/CrossGrading
(Stop afte
> I use a 32bit OS
>
> 32-bit OS can't use more than 4GB. 32-bit app can use even lower amount of
memory. This is why 50GB swap file didn't help.
Hi,
Reiner Buehl wrote.
> I would like to fix the filesystem
> so that I can then use more intelligent recovery methods that do not need to
> copy every file.
Maybe the old workaround proposed by Ted T'so in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614082
would be worth a try.
Bug rep
/ and /home are fine on the system. The data on the affected filesystem is
a collection of data from different remote sites, so it could be restored
but that would take a lot of time. That's why I would like to fix the
filesystem so that I can then use more intelligent recovery methods that do
not
On Mon, Jul 05, 2021 at 02:21:05PM -0700, Thomas D. Dean wrote:
On 7/5/21 1:54 PM, Michael Stone wrote:
On Mon, Jul 05, 2021 at 12:53:39PM +0300, IL Ka wrote:
7TB seems like too much for one partition imho.
Consider splitting it into the parts
That's silly. It's 2021; 7TB isn't particularly l
On 7/5/21 1:54 PM, Michael Stone wrote:
On Mon, Jul 05, 2021 at 12:53:39PM +0300, IL Ka wrote:
7TB seems like too much for one partition imho.
Consider splitting it into the parts
That's silly. It's 2021; 7TB isn't particularly large and there's no
value in breaking things into multiple parti
On Mon, Jul 05, 2021 at 12:53:39PM +0300, IL Ka wrote:
7TB seems like too much for one partition imho.
Consider splitting it into the parts
That's silly. It's 2021; 7TB isn't particularly large and there's no
value in breaking things into multiple partitions for no reason.
Reiner Buehl [2021-07-05 10:21:13] wrote:
> Hi all,
> I have a corrupt EXT4 filesystem where fsck.ext4 fails with the error
> message:
>
> Error storing directory block information (inode=366740508, block=0,
> num=406081): Memory allocation failed
[...]
> The system has 4GB of memory and a 8GB swap
On 7/5/2021 4:30 AM, Reiner Buehl wrote:
Hi all,
I have a corrupt EXT4 filesystem where fsck.ext4 fails with the error
message:
Error storing directory block information (inode=366740508, block=0,
num=406081): Memory allocation failed
/dev/vg_data/lv_mpg: * FILE SYSTEM WAS MODIFIED ***
On Mon, Jul 5, 2021 at 5:17 PM Reiner Buehl wrote:
> It seems swap is not the solution: Even after adding a 50G swap file, I
> still get the same error message and the swap usage stats from collectd
> show that max swap usage was not more than just 2G.
>
>
btw, do you use 32 or 64bit os?
It seems swap is not the solution: Even after adding a 50G swap file, I
still get the same error message and the swap usage stats from collectd
show that max swap usage was not more than just 2G.
I will now try if the scratch_files stanza makes a difference.
Am Mo., 5. Juli 2021 um 11:50 Uhr schr
Hi,
Reiner Buehl wrote:
> Is there a quick way to enlarge the swap space
According to old memories of mine you may create a large, non-sparse file
as you would do for a virtual disk. E.g. by mkfile (which seems not to be
in Debian) or qemu-img (from qemu-utils):
qemu-img create "$swap_file_pat
> Error storing directory block information (inode=366740508, block=0,
> num=406081): Memory allocation failed
>
Try ``scratch_files``
https://manpages.debian.org/buster/e2fsprogs/e2fsck.conf.5.en.html
This stanza controls when e2fsck will attempt to use scratch files to
reduce the need for memory
Hi all,
I have a corrupt EXT4 filesystem where fsck.ext4 fails with the error
message:
Error storing directory block information (inode=366740508, block=0,
num=406081): Memory allocation failed
/dev/vg_data/lv_mpg: * FILE SYSTEM WAS MODIFIED *
e2fsck: aborted
/dev/vg_data/lv_mpg: *
14 matches
Mail list logo
