0

After running bootinfoscript, I read on the log:

sda1: __________________________________________________________________________

File system:       ntfs
Boot sector type:  Windows XP: NTFS
Boot sector info:  According to the info in the boot sector, sda1 has 
                   78124992 sectors, but according to the info from 
                   fdisk, it has 81920000 sectors.
Operating System:  Windows XP
Boot files:        /boot.ini /bootmgr /Boot/BCD /ntldr /NTDETECT.COM

Windows and Linux boot fine on my system. Should I worry about this discrepancy? Is there a way to fix this?

I've already tried using Boot Repair, and I also followed this guide about TestDisk, but I didn't solve.

3
  • My guess is that one is sectors and the the other is blocks. No, I don't believe that anything is "wrong" so nothing to "fix", unless there is somthing actually not working, like a failure to find the MBR or bootsect. Mar 13, 2015 at 3:59
  • "Sectors" and "blocks" are usually identical; and when they're not, they'll be different by far more than the 5% reported here.
    – Rod Smith
    Mar 14, 2015 at 1:19
  • The number reported by fdisk looks like it's been rounded (2^{13} * 1000).
    – LDC3
    Mar 14, 2015 at 1:45

1 Answer 1

1

Chances are the discrepancy is the result of a partition- or filesystem-resizing operation that changed one of those things but not the other.

To elaborate, partitions are simple data structures that define a range of sectors on the disk that may be used for a particular purpose. Filesystems, OTOH, are much more complex data structures that help you store files. Filesystems are often stored on partitions, and partitions often hold filesystems, but this linkage isn't absolute. A partition, by its nature, defines a size -- 81,920,000 sectors, in your case. Filesystems also have sizes, which are defined independently of the partition -- 78,124,992 sectors, in your case. The two can get out of whack if a partition is resized without resizing the contained filesystem or if a filesystem is resized without resizing the containing partition. Tools to do both tasks exist in Linux, although some tools create or resize both partitions and filesystems simultaneously.

I'm not 100% positive, but I think that the following command, typed in Linux as root or using sudo, should fix the discrepancy:

ntfsresize /dev/sda1

This command resizes NTFS. The ntfsresize man page is a little unclear, but these tools usually resize to the size of the containing partition if no size is specified.

Note, however, that resizing filesystems is inherently dangerous. Given that there's only about a 5% discrepancy, and it's of a filesystem that's smaller than its partition, it's probably safer to just leave it be. A filesystem that's smaller than its partition poses no danger to the system; you're just losing a little disk space. If the filesystem were larger than its partition, that would pose a risk of data loss, but that's not the case for you.

1
  • Oh yes! I think you are right. Some time ago I resized my NTFS partition using this guide. As you said, one must pay attention, after having resized the filesystem, that the 'new' partition created with fdisk is big enough...I probably let fdisk round up things. Thanks for the clear explanation and the wise advice.
    – vap
    Mar 15, 2015 at 22:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .