Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1135867 > unrolled thread

Bug#1030252: debvm: debvm-create does not set all default ext4 features

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1030252: debvm: debvm-create does not set all default ext4 features Gioele Barabucci <gioele@svario.it> - 2023-02-01 18:10 +0100
    Bug#1030252: debvm: debvm-create does not set all default ext4 features Helmut Grohne <helmut@subdivi.de> - 2023-02-01 21:50 +0100
      Bug#1030252: debvm: debvm-create does not set all default ext4 features Gioele Barabucci <gioele@svario.it> - 2023-02-01 22:10 +0100
        Bug#1030252: debvm: debvm-create does not set all default ext4 features Helmut Grohne <helmut@subdivi.de> - 2023-02-02 10:10 +0100

#1135867 — Bug#1030252: debvm: debvm-create does not set all default ext4 features

Package: debvm
Version: 0.2.6

debvm-create converts the ext2 filesystem created by mmdebstrap to ext4 
using the following tune2fs command:

     tune2fs ... -O extents,uninit_bg,dir_index,has_journal "$IMAGE"

The ext4 filesystem created in this way does not have some of the 
features that a filesystem created with mkfs.ext4 would have:

     $ truncate -s "1GiB" e2
     $ /sbin/mkfs.ext2 e2
     $ /sbin/tune2fs -O extents,uninit_bg,dir_index,has_journal e2

     $ truncate -s "1GiB" e4
     $ /sbin/mkfs.ext4 e4

     $ diff -U7 <(/sbin/dumpe2fs ./e2 | grep -m1 feat | tr ' ' '\n')
                <(/sbin/dumpe2fs ./e4 | grep -m1 feat | tr ' ' '\n')

      has_journal
      ext_attr
      resize_inode
      dir_index
      filetype
      extent
     +64bit
     +flex_bg
      sparse_super
      large_file
     -uninit_bg
     +huge_file
     +dir_nlink
     +extra_isize
     +metadata_csum

My (debatable) expectation is that the ext4 filesystem would have at 
least all features of a standard ext4 filesystem.

Regards,

--
Gioele Barabucci

[toc] | [next] | [standalone]

#1135904

Control: forwarded -1 https://github.com/tytso/e2fsprogs/pull/118

On Wed, Feb 01, 2023 at 06:07:25PM +0100, Gioele Barabucci wrote:
> debvm-create converts the ext2 filesystem created by mmdebstrap to ext4
> using the following tune2fs command:
> 
>     tune2fs ... -O extents,uninit_bg,dir_index,has_journal "$IMAGE"
> 
> The ext4 filesystem created in this way does not have some of the features
> that a filesystem created with mkfs.ext4 would have:
> 
>     $ truncate -s "1GiB" e2
>     $ /sbin/mkfs.ext2 e2
>     $ /sbin/tune2fs -O extents,uninit_bg,dir_index,has_journal e2
> 
>     $ truncate -s "1GiB" e4
>     $ /sbin/mkfs.ext4 e4
> 
>     $ diff -U7 <(/sbin/dumpe2fs ./e2 | grep -m1 feat | tr ' ' '\n')
>                <(/sbin/dumpe2fs ./e4 | grep -m1 feat | tr ' ' '\n')
> 
>      has_journal
>      ext_attr
>      resize_inode
>      dir_index
>      filetype
>      extent
>     +64bit
>     +flex_bg
>      sparse_super
>      large_file
>     -uninit_bg
>     +huge_file
>     +dir_nlink
>     +extra_isize
>     +metadata_csum
> 
> My (debatable) expectation is that the ext4 filesystem would have at least
> all features of a standard ext4 filesystem.

This kinda is right. We could slightly improve this, but in the end we
want to replace genext2fs with mkfs.ext4 and that depends on it
supporting tarball input. So do you think we should mess with the
tune2fs invocation in the interim or is it good enough for now?

Helmut

[toc] | [prev] | [next] | [standalone]

#1135907

On 01/02/23 21:45, Helmut Grohne wrote:
> On Wed, Feb 01, 2023 at 06:07:25PM +0100, Gioele Barabucci wrote:
>> debvm-create converts the ext2 filesystem created by mmdebstrap to ext4
>> using the following tune2fs command:
>>
>>      tune2fs ... -O extents,uninit_bg,dir_index,has_journal "$IMAGE"
>>
>> The ext4 filesystem created in this way does not have some of the features
>> that a filesystem created with mkfs.ext4 would have:
>>
>> My (debatable) expectation is that the ext4 filesystem would have at least
>> all features of a standard ext4 filesystem.
> 
> This kinda is right. We could slightly improve this, but in the end we
> want to replace genext2fs with mkfs.ext4 and that depends on it
> supporting tarball input. So do you think we should mess with the
> tune2fs invocation in the interim or is it good enough for now?

Hi,

personally I stumbled upon this problem because my tests require 
`dir_nlink` (more than 65k subdirs per directory) and that feature was 
not enabled. Maybe other people have use-cases that depend on other 
missing features, but I doubt it.

IMO just copying the current set of features is enough as an interim 
solution to this minor (and temporary) problem.

Regards,

--
Gioele Barabucci

[toc] | [prev] | [next] | [standalone]

#1135964

Control: notforwarded -1
Control: tags -1 + pending

On Wed, Feb 01, 2023 at 10:06:43PM +0100, Gioele Barabucci wrote:
> personally I stumbled upon this problem because my tests require `dir_nlink`
> (more than 65k subdirs per directory) and that feature was not enabled.
> Maybe other people have use-cases that depend on other missing features, but
> I doubt it.
> 
> IMO just copying the current set of features is enough as an interim
> solution to this minor (and temporary) problem.

Great doing that with the exception of metadata_csum, which tune2fs
insists on doing interactively.

Helmut

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web