A discrepancy between fdisk and cfdisk.

stf92 · 04-18-2014, 07:52 PM

Code:

root@server:~# fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x4cf30742

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63    40965749    20482843+   7  HPFS/NTFS/exFAT
Partition 1 does not start on physical sector boundary.
/dev/sda2        40965752    83886080    21460164+  83  Linux
/dev/sda3        83886088    92274695     4194304   82  Linux swap
/dev/sda4        92277360   976768064   442245352+   f  W95 Ext'd (LBA)
/dev/sda5   *    92277423    94397939     1060258+   c  W95 FAT32 (LBA)
Partition 5 does not start on physical sector boundary.
/dev/sda6        94398003   976768064   441185031    7  HPFS/NTFS/exFAT
Partition 6 does not start on physical sector boundary.
root@server:~#

This is the hard disk I am running the OS from as I write (second partition, type 0x83). So, according to fdisk, sda6 is a type 0x07 logical partition. However, cfdisk declares this as a type 0x83 partition:

Code:

  sda6             Logical ext2  [ALMACEN]      451773.51

To who is right, I print the partition table (cfdisk, in table format):

Code:

Partition Table for /dev/sda

         ---Starting----      ----Ending-----    Start     Number of
 # Flags Head Sect  Cyl   ID  Head Sect  Cyl     Sector    Sectors
-- ----- ---- ---- ----- ---- ---- ---- ----- ----------- -----------
 1  0x80    1    1     0 0x07  254   63  2549          63    40965687
 2  0x00    0    3  2550 0x83  170    6  5221    40965752    42920329
 3  0x00  170   14  5221 0x82  212   45  5743    83886088     8388608
 4  0x00    0    1  5744 0x0F  254   63 60800    92277360   884490705
 5  0x80    1    1  5744 0x0C  254   63  5875          63     2120517
 6  0x00    1    1  5876 0x07  254   63 60800          63   882370062

This makes fdisk true. The ID column clearly shows the partition is not type 0x83 but 0x07. This was my first surprise. But there's more, though after this anything can be expected:

Code:

root@server:~# mount -tauto /dev/sda6 /mnt
root@server:~# mount
/dev/sda2 on / type ext2 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
gvfs-fuse-daemon on /home/semoi/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=semoi)
/dev/sda1 on /xp type fuseblk (rw,allow_other,blksize=4096)
/dev/sda6 on /mnt type ext2 (rw)

Am I dreaming, or actually there is nothing contradictory in these commands outputs?

EDIT: Now indeed I don't understand a ... The most reliable information is given by the entry in the hard disk consisting of one byte written as 0x07. So the partition has an NTFS filesystem on it. That is a fact. But it is a fact too that running e2fsck on the partition he doesn't complain and behaves as if he were checking an ext2/3/4 partition.

michaelk · 04-18-2014, 08:21 PM

Not really, the partition ID is just a label and linux does not care. Go ahead and change it to 83. Nothing will happen...

cfdisk actually verifies the filesystem while fdisk just reads the ID.

stf92 · 04-18-2014, 08:32 PM

Unbelievable! And I thought this was an all important datum! Thanks a lot.

EDIT: more surprises: According to mount, sda6 is not mounted. However, I am at this very moment editing one of the files in this partition?

michaelk · 04-18-2014, 08:45 PM

Are you sure? A mount point is a regular directory. If not mounted the files are written to the / partition vs sda6. You might unknowingly have two copies and can not see the / one if sda6 is mounted.

TobiSGD · 04-18-2014, 08:55 PM

On an unrelated topic: some of your partitions are not aligned properly, which will reduce write-speed on those partitions. On harddisk with 4KB physical sector size all start sectors should be divisible by 8.

stf92 · 04-18-2014, 08:59 PM

Yes the tree (very large in nodes and data) is in sda2://almacen, that is, this large set of files resides in /dev/sda2, where the OS resides. But in /etc/fstab I happen to mount sda6 under /almacen, and the large file set becomes invisible, the true contents of sda6 being visible instead (by executing ls /almacen).

All that matters is that this large file set is not in sda6 but in sda2. I will mount sda6 under another directory in fstab.

stf92 · 04-18-2014, 09:01 PM

Quote:

Originally Posted by TobiSGD

On an unrelated topic: some of your partitions are not aligned properly, which will reduce write-speed on those partitions. On harddisk with 4KB physical sector size all start sectors should be divisible by 8.

I know. I did not want to use parted, as it is a bit difficult to use and used cfdisk instead. As I understand, having read some posts, the price in velocity is not high.

rknichols · 04-18-2014, 11:40 PM

Quote:

Originally Posted by stf92

As I understand, having read some posts, the price in velocity is not high.

The impact of 4k sector misalignment on read operations is negligible. The impact on write operations is severe -- a factor of 10 or worse.

stf92 · 04-19-2014, 12:01 AM

And why does cfdisk not do a good job and so I must fall back on parted? I mean, cfdisk leaves the partitions misaligned, as far as I can remember.

TobiSGD · 04-19-2014, 04:50 AM

Quote:

Originally Posted by stf92

And why does cfdisk not do a good job and so I must fall back on parted? I mean, cfdisk leaves the partitions misaligned, as far as I can remember.

You will have to ask the cfdisk developers. But you don't have to use parted, in fact cfdisk is the only partitioning tool I know of with that behavior.

stf92 · 04-19-2014, 04:54 AM

From your words I infer that fdisk can do the job fine. Excellent! because it's an older tool, not ncurses.

stf92 · 04-20-2014, 09:19 AM

Quote:

Originally Posted by rknichols

The impact of 4k sector misalignment on read operations is negligible. The impact on write operations is severe -- a factor of 10 or worse.

You managed to worry me. As a result, I wanted to be sure a hard disk drive I have is 512-byte sectors. hdparm -I said nothing because the program version is too old. So I went to Western Digital, the drive manufacturer, and got the product specification for this WDC model WD1200BB (120 GB):
http://wdc.custhelp.com/app/answers/...00bb,-wd1200lb)

I only hope that the sectors mentioned here are physical sectors, though it could not be otherwise. The whole WDC part number is WD1200BB-55GU0 and the date stamped by the manufacturer on the drive case, whatever that date is, is 22 FEB 2006, a year when 4K-sector drives for home use were not yet manufactured, I think. No question is being made in this post.

rknichols · 04-20-2014, 12:06 PM

In your original post, the output from "fdisk -l" included

Code:

Sector size (logical/physical): 512 bytes / 4096 bytes
...
Partition 1 does not start on physical sector boundary.
...
Partition 5 does not start on physical sector boundary.
...
Partition 6 does not start on physical sector boundary.

That clearly states that the physical sector size is 4096 bytes and that you do have an alignment problem on 3 of your partitions on that 500GB drive. Now, you mention a 120GB drive that is not the same animal.

stf92 · 04-20-2014, 12:50 PM

Yes, quite a different drive. I hope I did not introduce confusion in the thread. This one is 512-byte sectored, as stated by the manufacturer and so poses no alignment problems to cfdisk, which is the tool I usually use. I once used parted to partition the drive I began speaking about, but as I had quite forgotten the way to use it but remembered I had to do some calculations I made up my mind to use cfdisk anyways, which now I see was a mistake.

Western Digital, the manufacturer of the 500GB drive, offer workarounds through an alignment tool, which simply relocates the entire file system to match logical and physical sectors. But I don't know how get that program.

rknichols · 04-20-2014, 01:18 PM

Ahhh, that explains it. A 120GB drive would indeed not have 4K physical sectors -- those came along later.

Moving a filesystem that is involved in the boot sequence needs to be done with knowledge of the boot loader involved and how to patch it back together after the move. While that WD tool might be able to handle a Windows boot partition, my confidence in its ability to handle a bootable Linux partition properly is just about zero. Fortunately, it appears that the alignment of your Linux partitions is OK, but would the tool try to move them anyway??

Moving a non-boot partition is straightforward in concept, but any glitch in that process will likely mean restoring from backup. You've actually got enough unallocated space on that drive to get those 3 partitions aligned without having to shrink anything, but that would be quite a "fiddly" process best done by copying an image of each partition to another device and copying it back to the aligned partition.