linux-ext4 - Re: Far too long mount time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAnFQG9L4==6V6kHg=ms8_5adBUUCj0f92RQHAPdo8yac9XcdA@mail.gmail.com>
Date:	Thu, 16 Aug 2012 11:18:31 +0200
From:	Javier Marcet <jmarcet@...il.com>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Linux Ext4 Mailing List <linux-ext4@...r.kernel.org>
Subject: Re: Far too long mount time

On Thu, Aug 16, 2012 at 11:09 AM, Andreas Dilger <adilger@...ger.ca> wrote:

>> I'm in the process of setting up a new software raid with four 3TB disks.
>> So far I'm doing the tests using also bcache on a 60GB partition on a 120GB
>> SSD. Everything is protected by a UPS.
>>
>> On the software side: self compiled kernel 3.5.1 and util-linux 2.20.1
>>
>> Thus far, ext4 is doing really really well but for one thing, the mount
>> time. At the moment I'm testing a RAID5 which makes the partition 8.2TB.
>>
>> ext4 takes:
>> $ time mount /mnt/raid
>> 0.00s user 79.49s system 92% cpu 1:26.25 total
>>
>> xfs, OTOH, is way faster:
>> time mount /mnt/raid
>> 0.00s user 0.01s system 0% cpu 1.869 total
>>
>> I'v tried everything I could think of but the mount time remains constant.
>> Is there anything I can do to speed up the mount time?
>
> Did you format the filesystem with "mke2fs -t ext4"?  Without the "-t ext4" option, you won't get the "flex_bg" formatting option, which improves the layout of the filesystem metadata, and definitely reduces mount times.

Hmm, I used mkfs.ext4. Loooking at /etc/mke2fs.conf :

defaults]
        base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
        default_mntopts = acl,user_xattr
        enable_periodic_fsck = 0
        blocksize = 4096
        inode_size = 256
        inode_ratio = 16384

[fs_types]
        ext3 = {
                features = has_journal
        }
        ext4 = {
                features =
has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
                auto_64-bit_support = 1
                inode_size = 256
        }

It looks like flex_bg is being used.

> It is a bit strange that _mounting_ uses 92% CPU.  Hmm, there was a bug
> reported for 3.5.1, see "Re: Upgraded from 3.4 to 3.5.1 kernel: machine

That also surprised me. At first I thought it was bcache, but with zfs the
behavior is normal.

> does not boot", and reverting the patch with git commit hash
> "8aeb00ff85ad25453765dd339b408c0087db1527" resolved the problem.  This
> slowdown was only seen with larger devices.

I'll check it right now.

I've reverted it and I'm compiling the new kernel. I'll keep you
posted on the results.

By the way, when you say larger, you mean much larger than 8TB?


-- 
Javier Marcet <jmarcet@...il.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html