Re: Xfs partition info seems to be lost on reboot

[Eric Sandeen <sandeen@xxxxxxx>]

I'm guessing there's a problem with parted somewhere....  you might use 
fdisk to print the partition headers and see if it looks ok - if not, I 
guess either fdisk or parted has a problem.  I suppose the only way to 
know for sure is to dump the partition table from the disk and poke 
around in it to see if it's writing what you think it's writing.

One other test, try looking at /proc/partitions before & after the 
reboot - how does your device size look?

excursion into CONFIG_LBD below...

Jan Derfinak wrote:

> I'm curious, why there is CONFIG_LBD on 64-bit architecture?
> Is there because of VFS issue?

I guess CONFIG_LBD is settable on x86_64 because:

config LBD
        bool "Support for Large Block Devices"
        depends on X86 || MIPS32 || PPC32 || ARCH_S390_31 || SUPERH

and x86_64 -does- set CONFIG_X86....  but it should not make any 
difference I think.

The main LBD "switch" is the size of sector_t.  It's set in 
include/linux/types.h unless HAVE_SECTOR_T is set:

#ifndef HAVE_SECTOR_T
typedef unsigned long sector_t;
#endif

include/asm-i386/types.h overrides this if CONFIG_LBD is on:

#ifdef CONFIG_LBD
typedef u64 sector_t;
#define HAVE_SECTOR_T
#endif

but include/asm-x86_64/types.h sets it regardless:

typedef u64 sector_t;
#define HAVE_SECTOR_T

XFS code shouldn't care; when it tests for CONFIG_LBD in xfs_linux.h it 
also tests for BITS_PER_LONG == 64, and the only other test for 
CONFIG_LBD is only under BITS_PER_LONG == 32.

The only other question I'd have about it is how the do_div macro 
ultimately winds up getting defined...

More than you probably wanted to know about LBD, and probably doesn't 
answer your question.  :)


-Eric