[Ocfs2-devel] Large (> 16TiB) volumes revisited
Joel Becker
Joel.Becker at oracle.com
Tue Jun 22 18:36:34 PDT 2010
On Tue, Jun 22, 2010 at 06:12:01PM -0700, Patrick J. LoPresti wrote:
> On Tue, Jun 22, 2010 at 5:49 PM, Joel Becker <Joel.Becker at oracle.com> wrote:
> > On Tue, Jun 22, 2010 at 05:11:50PM -0700, Patrick J. LoPresti wrote:
> >
> > This patch is not sufficient. The journal options need to be
> > checked, as does the block addressing space of the kernel.
>
> OK. But I am new to this code base and would appreciate some pointers...
>
> Specifically:
>
> Which journal options? Are they visible at this point in super.c?
JBD2_FEATURE_INCOMPAT_64BIT. You'll need to call
jbd2_journal_check_used_features() to see if the journal has it enabled.
Before you can do that, you have to ensure that the filesystem has the
OCFS2_FEATURE_COMPAT_JBD2_SB feature enabled.
> By "block addressing space of the kernel", are we just talking
> sizeof(some_kernel_type) or something more involved?
sector_t. You can copy what ext4 did here.
2709 if ((ext4_blocks_count(es) >
2710 (sector_t)(~0ULL) >> (sb->s_blocksize_bits - 9)) ||
2711 (ext4_blocks_count(es) >
2712 (pgoff_t)(~0ULL) >> (PAGE_CACHE_SHIFT - sb->s_blocksize_bits)) ) {
2713 ext4_msg(sb, KERN_ERR, "filesystem"
2714 " too large to mount safely on this system");
blocks_count is, of course, the calculation we already perform
to turn di->i_clusters into how many blocks we have.
We must always fail if we can't address our disk in sector_t.
Once we've gotten past that check, we then need to figure out if our
journal can address our entire disk. So if our current test for ">
(u32)~0UL" returns true, one must then check for the 64BIT feature.
Joel
--
"You don't make the poor richer by making the rich poorer."
- Sir Winston Churchill
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127
More information about the Ocfs2-devel
mailing list