All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Mikhail Morfikov <mmorfikov@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Is it safe to use the bigalloc feature in the case of ext4 filesystem?
Date: Thu, 29 Jul 2021 13:59:51 -0400	[thread overview]
Message-ID: <YQLsl7s/GcgMGi47@mit.edu> (raw)
In-Reply-To: <ba95a978-18af-794a-4c9d-a8406ade31ae@gmail.com>

On Wed, Jul 28, 2021 at 11:36:27AM +0200, Mikhail Morfikov wrote:
> Thanks for the answer.
> 
> I have one question. Basically there's the /etc/mke2fs.conf file and 
> I've created the following stanza in it:
> 
> bigdata = {
>                 errors = remount-ro
>                 features = has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize,bigalloc,^uninit_bg,sparse_super2
>                 inode_size = 256
>                 inode_ratio = 4194304
>                 cluster_size = 4M
>                 reserved_ratio = 0
>                 lazy_itable_init = 0
>                 lazy_journal_init = 0
>         }
> 
> It looks like the cluster_size parameter is ignored in such case (I've 
> tried both 4M and 4194304 values), and the filesystem was created with 
> 64K cluster size (via mkfs -t bigdata -L bigdata /dev/sdb1 ), which is 
> the default when the bigalloc feature is set.

It does work, but you need to use an integer value for cluster_size,
and it needs to be in the [fs_types[ section.  So something like what I
have attached below.

And then try using the command "mke2fs -t ext4 -T bigdata -L bigdata
/dev/sdb1".

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.

Cheers,

						- Ted

[defaults]
	base_features = sparse_super,large_file,filetype,resize_inode,dir_index,ext_attr
	default_mntopts = acl,user_xattr
	enable_periodic_fsck = 0
	blocksize = 4096
	inode_size = 256
	inode_ratio = 16384
	undo_dir = /var/lib/e2fsprogs/undo

[fs_types]
	ext3 = {
		features = has_journal
	}
	ext4 = {
		features = has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize
		inode_size = 256
	}
	small = {
		blocksize = 1024
		inode_size = 128
		inode_ratio = 4096
	}
	floppy = {
		blocksize = 1024
		inode_size = 128
		inode_ratio = 8192
	}
	big = {
		inode_ratio = 32768
	}
	huge = {
		inode_ratio = 65536
	}
	news = {
		inode_ratio = 4096
	}
	largefile = {
		inode_ratio = 1048576
		blocksize = -1
	}
	largefile4 = {
		inode_ratio = 4194304
		blocksize = -1
	}
	hurd = {
	     blocksize = 4096
	     inode_size = 128
	}
	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
	}
	bigdata = {
		errors = remount-ro
		features = has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize,bigalloc,^uninit_bg,sparse_super2
		inode_size = 256
		inode_ratio = 4194304
		cluster_size = 4194304
		reserved_ratio = 0
		lazy_itable_init = 0
		lazy_journal_init = 0
	}

  reply	other threads:[~2021-07-29 17:59 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 [this message]
2021-07-29 18:32       ` Mikhail Morfikov
2021-07-30 13:57       ` Mikhail Morfikov

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=YQLsl7s/GcgMGi47@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mmorfikov@gmail.com \
    /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.