Speed of mkfs.ext4 on large HDD

  • Hi,


    I set up OMV on an old server with an AMD Turion II 2GB RAM and SSD as system partition,

    I have a 16TB drive that I put LUKS on with the help of OMV extras and now want format it with ext4.


    That seems to take forever...


    Is there any way like quick format under Windows to boost that process despite the hardware?!

    HP ProLiant N40l - AMD Turion II, 2GB RAM, 120GB SSD, 16TB HDD, OMV 7

  • crashtest

    Approved the thread.
    • Official Post

    Is there any way like quick format under Windows to boost that process despite the hardware?!

    Formatting from the command line would be faster on old slow hardware but this is a one time process. Just be patient.

    omv 7.4.0-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.1 | k8s 7.2.0-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.8


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Thanks.

    The server is standing in my homeoffice and quite loud - I want to use it for weekly backups. So having it run as short as possible would be great.

    So just


    mkfs.ext4 -m0 /dev/mapper/name_of_opened_luks


    with ssh?

    Any downsides of this way?

    HP ProLiant N40l - AMD Turion II, 2GB RAM, 120GB SSD, 16TB HDD, OMV 7

    • Official Post

    Sure. The LUKS part was slowing it down the most.

    omv 7.4.0-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.1 | k8s 7.2.0-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.8


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!


  • It took about 20 seconds .... making ext4 in OMV I stopped after 5 minutes having just written a fraction (blocks or headers).


    Seems to be wrong somehow?!

    HP ProLiant N40l - AMD Turion II, 2GB RAM, 120GB SSD, 16TB HDD, OMV 7

    • Official Post

    Seems to be wrong somehow?!

    Nope. Your drive is just finishing the work in the background where OMV was making sure it was done. OMV uses these arguments:


    -b 4096 -m 0 -E lazy_itable_init=0,lazy_journal_init=0


    From the man page:


    Quote

    lazy_itable_init[= <0 to disable, 1 to enable>]If enabled and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs. This speeds up filesystem initialization noticeably, but it requires the kernel to finish initializing the filesystem in the background when the filesystem is first mounted. If the option value is omitted, it defaults to 1 to enable lazy inode table zeroing.

    lazy_journal_init[= <0 to disable, 1 to enable>]If enabled, the journal inode will not be fully zeroed out by mke2fs. This speeds up filesystem initialization noticeably, but carries some small risk if the system crashes before the journal has been overwritten entirely one time. If the option value is omitted, it defaults to 1 to enable lazy journal inode zeroing.

    omv 7.4.0-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.1 | k8s 7.2.0-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.8


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!