From: Mikhail Morfikov <mmorfikov@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Is it safe to use the bigalloc feature in the case of ext4 filesystem?
Date: Fri, 30 Jul 2021 15:57:49 +0200 [thread overview]
Message-ID: <1aa38330-eaed-ab37-b941-203d970a7727@gmail.com> (raw)
In-Reply-To: <YQLsl7s/GcgMGi47@mit.edu>
I have a question concerning the *hugefiles* parameters. When a
filesystems is created using the hugefiles stanza, it also creates
lots of chunk-* files inside of the /storage/ dir. You say that it
guarantees the huge files to be 100% contiguous. But if I create
the filesystem with the preallocated files that consume the whole
drive, how am I suppose to use that drive? :) Are the files only
temporary, and should they be removed once the filesystem is
"ready"? What's the purpose of such options? Do they affect the
EXT4 metadata in some way? I mean, what's the change compared to
not using the options?
Also I have a question concerning the hugefiles stanza
itself -- it's missing the bigalloc feature, should it be there?
On 29/07/2021 19.59, Theodore Ts'o wrote:
>...
> If you see the hugefile and hugefiles stanzas below, that's an example
> of one way bigalloc has gotten a fair amount of use. In this use case
> mke2fs has pre-allocated the huge data files guaranteeing that they
> will be 100% contiguous. We're using a 32k cluster becuase there are
> some metadata files where better allocation efficiencies is desired.
>
>...
>
> hugefiles = {
> features = extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize,^resize_inode,sparse_super2
> hash_alg = half_md4
> reserved_ratio = 0.0
> num_backup_sb = 0
> packed_meta_blocks = 1
> make_hugefiles = 1
> inode_ratio = 4194304
> hugefiles_dir = /storage
> hugefiles_name = chunk-
> hugefiles_digits = 5
> hugefiles_size = 4G
> hugefiles_align = 256M
> hugefiles_align_disk = true
> zero_hugefiles = false
> flex_bg_size = 262144
> }
>
> hugefile = {
> features = extent,huge_file,bigalloc,flex_bg,uninit_bg,dir_nlink,extra_isize,^resize_inode,sparse_super2
> cluster_size = 32768
> hash_alg = half_md4
> reserved_ratio = 0.0
> num_backup_sb = 0
> packed_meta_blocks = 1
> make_hugefiles = 1
> inode_ratio = 4194304
> hugefiles_dir = /storage
> hugefiles_name = huge-file
> hugefiles_digits = 0
> hugefiles_size = 0
> hugefiles_align = 256M
> hugefiles_align_disk = true
> num_hugefiles = 1
> zero_hugefiles = false
> }
prev parent reply other threads:[~2021-07-30 13:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-23 15:30 Is it safe to use the bigalloc feature in the case of ext4 filesystem? Mikhail Morfikov
2021-07-27 6:24 ` Andreas Dilger
2021-07-27 23:01 ` Theodore Ts'o
2021-07-28 9:36 ` Mikhail Morfikov
2021-07-29 17:59 ` Theodore Ts'o
2021-07-29 18:32 ` Mikhail Morfikov
2021-07-30 13:57 ` Mikhail Morfikov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1aa38330-eaed-ab37-b941-203d970a7727@gmail.com \
--to=mmorfikov@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.