linux-ext4 - Re: Missing JBD2_FEATURE_INCOMPAT

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: <20070419211817.GO5967@schatzie.adilger.int>
Date:	Thu, 19 Apr 2007 15:18:17 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Mingming Cao <cmm@...ibm.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Missing JBD2_FEATURE_INCOMPAT_64BIT in ext4

On Apr 19, 2007  12:15 -0700, Mingming Cao wrote:
> On Sun, 2007-04-15 at 10:16 -0600, Andreas Dilger wrote:
> > Just a quick note before I forget.  I thought there was a call in ext4
> > to set JBD2_FEATURE_INCOMPAT_64BIT at mount time if the filesystem has
> > more than 2^32 blocks?
> 
> Question about the online resize case. If the fs is increased to more
> than 2^32 blocks, we should set this JBD2_FEATURE_INCOMPAT_64BIT in the
> journal. What about existing transactions that still stores 32 bit block
> numbers?  I guess the journal need to commit them all so that revoke
> will not get confused about the bits for block numbers later.  After
> that done then JBD2 can set this feature safely.

Well, there are two options here:
1) refuse resizing filesystems beyond 16TB
   - this is required if they were not formatted as ext4 to start with, as
     the group descriptors will not be large enough to handle the "_hi"
     word in the bitmap/inode table locations
   - this is also a problem for block-mapped files that need to allocate
     blocks beyond 16TB (though this could just fail on those files with
     e.g. ENOSPC or EFBIG or something similar)
2) flush the journal (like ext4_write_super_lockfs()) while resizing beyond
   16TB.  This would also require changing over to META_BG at some point,
   because there cannot be enough reserved group descriptor blocks (the
   resize_inode is set up for a maximum of 2TB filesystems I think)
   
For now I'd be happy with just setting the JBD2_*_64BIT flag at mount for
filesystems > 16TB, and refusing resize across 16TB.  We can fix it later.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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