[opensuse] Fwd: Performance penalty for mis-aligned partitions on a 4K physical sector drive
Resend without HTML
On Monday, March 16, 2015, Anton Aylward
On 03/16/2015 09:32 AM, Greg Freemyer wrote:
If you are going to use drives with 4KB physical sectors you need to avoid filesystems with 1KB blocks.
I'm sure there are many in the silent majority here who don't have the detailed knowledge, or, like me, have let it pass them by since they deal with other matters (such as users and applications), and wonder about one or another implication in that statement.
We've seen the example with mkfs or extFS for various block sizes, but what about other file systems?
And more to the point for most of us:
How can we tell about these things?
* What block size the disks are are
I suppose all late model disks are 4K :-)
* what size the file system blocks are for the file systems in use - Not just extFS but XFS, reiserFS, BtrFS - if the are not 4K what can we do about it?
* Some might ask about the other file systems in /proc/filesystems. - Does it matter with tmpfs? What about when it 'overflows' to /tmp?
* How can we tell if they are aligned? - if they are not, what can we do about it?
Either it matters, and these are the questions that emerge, or it doesn't.
It matters, but for most people, they do normal things and it works out fine. The developers have addressed their needs. Felix is a different kind of creature :) He takes a TB or larger drive and puts a bunch of small partitions: == From one of Felix's posts == Device Boot Start End Blocks Id System /dev/sda1 63 80324 40131 6 FAT16 /dev/sda2 80325 578339 249007+ 1c Hidden W95 FAT32 (LBA) /dev/sda3 * 578340 1397654 409657+ 83 Linux /dev/sda4 1397655 625137344 311869845 5 Extended /dev/sda5 1397718 4466069 1534176 82 Linux swap / Solaris /dev/sda6 4466133 4482134 8001 1 FAT12 /dev/sda7 4482198 4996214 257008+ 6 FAT16 /dev/sda8 4996278 19743884 7373803+ 83 Linux /dev/sda9 19743948 28756349 4506201 83 Linux /dev/sda10 28756413 40226759 5735173+ 83 Linux /dev/sda11 40226823 78959474 19366326 83 Linux /dev/sda12 78959538 81417419 1228941 83 Linux /dev/sda13 81417483 91249199 4915858+ 83 Linux /dev/sda14 91249263 101080979 4915858+ 83 Linux /dev/sda15 101081043 110912759 4915858+ 83 Linux /dev/sda16 110912823 120744539 4915858+ 83 Linux /dev/sda17 120744603 130576319 4915858+ 83 Linux /dev/sda18 130576383 140408099 4915858+ 83 Linux /dev/sda19 140408163 150239879 4915858+ 83 Linux /dev/sda20 150239943 160071659 4915858+ 83 Linux /dev/sda21 160071723 171542069 5735173+ 83 Linux /dev/sda22 171542133 181373849 4915858+ 83 Linux /dev/sda23 252525798 262357514 4915858+ 83 Linux /dev/sda24 262357578 272189294 4915858+ 83 Linux /dev/sda25 272189358 282021074 4915858+ 83 Linux /dev/sda26 282021138 291852854 4915858+ 83 Linux /dev/sda27 291852918 301684634 4915858+ 83 Linux /dev/sda28 301684698 311516414 4915858+ 83 Linux /dev/sda29 311516478 624093119 156288321 83 Linux /dev/sda30 624093183 625137344 522081 e W95 FAT16 (LBA) ====== The defaults simply break in those conditions, so Felix has to concern himself with issues the rest of us never have come up. If you look at the above you see he has a lot of partitions that start on a odd sector. That is bad today. Typical modern partitioning tools will align all partitions to 1MB. Felix needs to adopt a 21st century partitioning mechanism. Then you can see that many of his partitions are only 2GB of so. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Mar 17, 2015 at 11:43 AM, Greg Freemyer
Resend without HTML
On Monday, March 16, 2015, Anton Aylward
wrote: On 03/16/2015 09:32 AM, Greg Freemyer wrote:
If you are going to use drives with 4KB physical sectors you need to avoid filesystems with 1KB blocks.
I'm sure there are many in the silent majority here who don't have the detailed knowledge, or, like me, have let it pass them by since they deal with other matters (such as users and applications), and wonder about one or another implication in that statement.
We've seen the example with mkfs or extFS for various block sizes, but what about other file systems?
And more to the point for most of us:
How can we tell about these things?
* What block size the disks are are
I suppose all late model disks are 4K :-)
* what size the file system blocks are for the file systems in use - Not just extFS but XFS, reiserFS, BtrFS - if the are not 4K what can we do about it?
* Some might ask about the other file systems in /proc/filesystems. - Does it matter with tmpfs? What about when it 'overflows' to /tmp?
* How can we tell if they are aligned? - if they are not, what can we do about it?
Either it matters, and these are the questions that emerge, or it doesn't.
It matters, but for most people, they do normal things and it works out fine. The developers have addressed their needs.
Right. Where it pops up is when physical sector size isn't passing through various layers. I think the libvirt stuff even has this right, but honestly I haven't checked to see if e.g. a qcow2 file on a 512e drive shows up inside the VM as a 512e drive. If blockdev is thwarted in learning the actual physical sector size, for whatever reason, then the mkfs utilities have no chance with defaults. At least on x86: ext[234] You probably don't have to worry about on anything larger than ~500MiB or whatever it is, you get a 4KiB block size. XFS is always a 4KiB block size, but the journal updates can have a smaller unit matching physical sector size. So if physical sector size is 4096 bytes but wrongly reported by blockdev as 512 bytes, then there could be a performance impact with heavy metadata writes causing a lot of RMW in the drive, just for the journal writes however. I'm not sure how noticeable it'd be. Btrfs is always a 4KiB block size, with a 16KiB node/leaf size by default, which is efficiently used (multiple file extent refs can be stored in one leaf as can inline data for small files.)
The defaults simply break in those conditions, so Felix has to concern himself with issues the rest of us never have come up.
Using VM's backed with qcow2 files would make this a lot easier and more space efficient. Resizes are both possible and easier.
If you look at the above you see he has a lot of partitions that start on a odd sector. That is bad today. Typical modern partitioning tools will align all partitions to 1MB. Felix needs to adopt a 21st century partitioning mechanism.
If the MBR or any EBR sector were to corrupt or read error, all subsequent partition info is lost, unless this information is separately backed up. GPT of course has two copies of everything, and are checksummed. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
Felix is a different kind of creature :)
He takes a TB or larger drive and puts a bunch of small partitions:
== From one of Felix's posts == Device Boot Start End Blocks Id System /dev/sda1 63 80324 40131 6 FAT16 /dev/sda2 80325 578339 249007+ 1c Hidden W95 FAT32 (LBA) /dev/sda3 * 578340 1397654 409657+ 83 Linux /dev/sda4 1397655 625137344 311869845 5 Extended /dev/sda5 1397718 4466069 1534176 82 Linux swap / Solaris ...
The defaults simply break in those conditions, so Felix has to concern himself with issues the rest of us never have come up.
If you look at the above you see he has a lot of partitions that start on a odd sector. That is bad today. Typical modern partitioning tools will align all partitions to 1MB. Felix needs to adopt a 21st century partitioning mechanism.
Then you can see that many of his partitions are only 2GB of so.
Hey, I do similar, but with lvs: 3> lvs LV VG Attr LSize Pool Origin Data% Backup Backup -wi-ao--- 12.00t Media Backup -wc-ao--- 9.80t Home Data owc-aos-- 1.50t Home-2015.02.17-03.07.03 Data -wi-ao--- 796.00m Home-2015.02.21-03.07.03 Data -wi-ao--- 1004.00m Home-2015.03.01-03.07.03 Data -wi-ao--- 884.00m Home-2015.03.03-03.07.03 Data -wi-ao--- 812.00m Home-2015.03.05-03.07.03 Data -wi-ao--- 868.00m Home-2015.03.07-03.07.02 Data -wi-ao--- 740.00m Home-2015.03.09-03.07.02 Data -wi-ao--- 856.00m Home-2015.03.10-03.07.02 Data -wi-ao--- 984.00m Home-2015.03.11-03.07.03 Data -wi-ao--- 1.14g Home-2015.03.12-03.07.02 Data -wi-ao--- 868.00m Home-2015.03.13-03.07.06 Data -wi-ao--- 1000.00m Home-2015.03.16-03.07.12 Data -wi-ao--- 840.00m Home-2015.03.17-03.07.03 Data swi-aos-- 1.50t Home 0.02 Home.diff Data -wi-ao--- 512.00g Lmedia Data -wi-ao--- 8.00t Local Data -wi-ao--- 1.50t Media Data -wc-ao--- 10.00t Share Data -wc-ao--- 1.50t Squid_Cache Data -wc-ao--- 128.00g Sys Data -wc-a---- 96.00g Sysboot Data -wc-a---- 4.00g Sysvar Data -wc-a---- 28.00g UsrShare Data -wc-ao--- 50.00g Win Data -wi-a---- 1.00t cptest Data -wi-ao--- 5.00g ---- It's not that he creates tons of small partitions -- many of my snapshots are under 1G. It's just a matter of setting defaults when you create the VG's and LV's. Every one of those should be lined up. Then my xfs create script goes out and checks the actual block size: ... my rdev=$(get_real_dev "$dev") if [[ ${rdev:0:2} == sd ]]; then rdev=${rdev:0:3}; fi int blksize=$(get_phys_block_size "$rdev") if ((blksize!=512 && blksize!=4096)); then echo "Unexpected block size $(Q "$blksize"). Stopping." exit 3 fi ... then adjusts a few params to compensate for the larger block size: ... : ${sector_size:=$blksize} : ${inode_percent:=5} : ${su:=64k} ${sw:=1} : ${log_bs:=${log_bsi}k} : ${lazy_count:=1} if ((sector_size==4096)); then : ${inode_size:=256} : ${inode_percent:=10} fi ... --- Anton -- if you just script it you should be able to ensure any FS is lined up. It is important to get the pd's reserving the right amount in the front of the disk and get the right alloc size for the VGs and LVs... I changed the inode params so I by default it would be likely to take fewer double-reads (make them larger than default because I use ACL's alot)... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Mar 17, 2015 at 4:39 PM, Linda Walsh
Greg Freemyer wrote:
Then you can see that many of his partitions are only 2GB of so.
--- Hey, I do similar, but with lvs: 3> lvs LV VG Attr LSize Pool Origin Data% Backup Backup -wi-ao--- 12.00t Media Backup -wc-ao--- 9.80t Home Data owc-aos-- 1.50t Home-2015.02.17-03.07.03 Data -wi-ao--- 796.00m Home-2015.02.21-03.07.03 Data -wi-ao--- 1004.00m Home-2015.03.01-03.07.03 Data -wi-ao--- 884.00m Home-2015.03.03-03.07.03 Data -wi-ao--- 812.00m Home-2015.03.05-03.07.03 Data -wi-ao--- 868.00m Home-2015.03.07-03.07.02 Data -wi-ao--- 740.00m Home-2015.03.09-03.07.02 Data -wi-ao--- 856.00m Home-2015.03.10-03.07.02 Data -wi-ao--- 984.00m Home-2015.03.11-03.07.03 Data -wi-ao--- 1.14g Home-2015.03.12-03.07.02 Data -wi-ao--- 868.00m Home-2015.03.13-03.07.06 Data -wi-ao--- 1000.00m Home-2015.03.16-03.07.12 Data -wi-ao--- 840.00m Home-2015.03.17-03.07.03 Data swi-aos-- 1.50t Home 0.02 Home.diff Data -wi-ao--- 512.00g Lmedia Data -wi-ao--- 8.00t Local Data -wi-ao--- 1.50t Media Data -wc-ao--- 10.00t Share Data -wc-ao--- 1.50t Squid_Cache Data -wc-ao--- 128.00g Sys Data -wc-a---- 96.00g Sysboot Data -wc-a---- 4.00g Sysvar Data -wc-a---- 28.00g UsrShare Data -wc-ao--- 50.00g Win Data -wi-a---- 1.00t cptest Data -wi-ao--- 5.00g ---- It's not that he creates tons of small partitions -- many of my snapshots are under 1G. It's just a matter of setting defaults when you create the VG's and LV's.
You gain a lot of flexibility for free though with LVM because everything is by default on 4MiB boundaries, even when discontinuous. You could use vgcreate -s to specify something below 4KiB, but ohnoez why?? [[Off topic but I'm wondering if those are LVM thin volume (snapshots)? Or are they the conventional ones? It seems like you have a good use case for thin volumes there. Not only are the snapshots faster, and independent (you can delete either the origin or destination LV, just like Btrfs snapshots/subvolumes), but you unlike Btrfs they can be thinly provisioned, almost totally obviating any need to resize a fs. shrink = fstrim grow = Just start the thing out at 4x the size you think you'll ever need in its lifetime.]]
Every one of those should be lined up.
Then my xfs create script goes out and checks the actual block size: ... my rdev=$(get_real_dev "$dev") if [[ ${rdev:0:2} == sd ]]; then rdev=${rdev:0:3}; fi int blksize=$(get_phys_block_size "$rdev") if ((blksize!=512 && blksize!=4096)); then echo "Unexpected block size $(Q "$blksize"). Stopping." exit 3 fi ...
If you assume most or all drive now are 512e (512 byte logical/4096 byte physical), you could just always use mkfs.xfs -s 4096. There is an infinitesimal negative of minimum _log_ IO size being 4096 bytes when the actual physical sector is 512 bytes; the inverse of that is not true though. There might be justification for -s 4096 becoming the default in the not too distant future. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 18 Mar 2015 00:12, Chris Murphy wrote:
On Tue, Mar 17, 2015 at 4:39 PM, Linda Walsh wrote:
Every one of those should be lined up.
Then my xfs create script goes out and checks the actual block size: ... my rdev=$(get_real_dev "$dev") if [[ ${rdev:0:2} == sd ]]; then rdev=${rdev:0:3}; fi int blksize=$(get_phys_block_size "$rdev") if ((blksize!=512 && blksize!=4096)); then echo "Unexpected block size $(Q "$blksize"). Stopping." exit 3 fi ...
If you assume most or all drive now are 512e (512 byte logical/4096 byte physical), you could just always use mkfs.xfs -s 4096. There is an infinitesimal negative of minimum _log_ IO size being 4096 bytes when the actual physical sector is 512 bytes; the inverse of that is not true though.
There might be justification for -s 4096 becoming the default in the not too distant future.
Well, grab the real disk info (hdparm,smartctl,etc) first. Size is also a matter. For rotating drives below the 1TB mark, are there 4kn / 512e drives available? Most info I got was 512, but is that native or emulated? For 512e drives, well, they profit from handling them as 4k drives. But, there is still a lot of older Raid Hardware in use, that simply is unable to handle 4k drives. How should that be addressed? -- Or, does it matter, really? Handling partitions aligned to 1024k (1MB) should not have a negative impact on 512(n|e) drives, even over hw-raid. A inode smaller than 512 byte is not well handled in times of xattr, and ACLs, as well as long file / directory in UTF-8. So, a packing 8 inodes in a 4k block is not that false. And the "gruft" / space loss at 4k granuality for files is not the negative impact it once was. Yes, I remember 4GB scsii drives as the "state of the art". I've retired the last ones in 2010, including the HW-Raid controller they where on -- a good run since 1998. So, a changeable "default" of 1024k for partitions, and 4k as principal block size is a preferable way to go forward. For me the choice of just "what" FS to use has much more impact than "blocksize" / "inodesize". Lets overhaul the defaults (incl /etc/mke2fs.conf) based on ssd (4k) / rotating rust (512/4k) and size: above 2TB 4k only, below 1TB 512 / check , between? - I'd opt for 4k as default -- and just where are defaults for BTRFS and XFS stored, only in the code / binary ? On the list of things I'm missing is a LVM-HOWTO with examples esp. for "Thin-Provisioning" sure info on that in one location is as rare as a egg-laying wool-giving pigs. I'm still using ReiserFS for code / git / mercury stuff with exeedingly small files and masses of deletes and creates. BTRFS has still a way to go to reach ReiserFS for such cases. And for long-term external drives / sticks BTRFS is not mature enough, maybe in another 2 years. XFS has gotten better in the last 6 years, but removing big trees, sync, create a new big tree, sync is still a good part slower. (15%-25% more time than ReiserFS, but that was 3times slower, 6years ago) End of rant, atm. - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Mar 17, 2015 at 6:01 PM, Yamaban
On Wed, 18 Mar 2015 00:12, Chris Murphy wrote:
There might be justification for -s 4096 becoming the default in the not too distant future.
Well, grab the real disk info (hdparm,smartctl,etc) first.
None of the mkfs tools do this, they trust blockdev. I'm suggesting -s 4096 always for XFS is a better default, even if it's wrong for 512n drives, than it is to get it wrong for 512e or 4096n drives. Of course if the user knows better, they'd still be able to use -s 512 for 512n drives. But this is totally hypothetical, I'm not aware of such a suggestion being made on the XFS devel list.
But, there is still a lot of older Raid Hardware in use, that simply is unable to handle 4k drives.
How should that be addressed? -- Or, does it matter, really?
Different problem, it's up to that RAID vendor to determine support.
Handling partitions aligned to 1024k (1MB) should not have a negative impact on 512(n|e) drives, even over hw-raid.
Correct. Hardware vs software RAID doesn't matter in such a case though.
So, a changeable "default" of 1024k for partitions, and 4k as principal block size is a preferable way to go forward.
Yes it's been this way for quite a while. The partial exception being 512n drives with small partitions formatted with ext[234] get a 1KiB block size.
For me the choice of just "what" FS to use has much more impact than "blocksize" / "inodesize".
Lets overhaul the defaults (incl /etc/mke2fs.conf) based on ssd (4k) / rotating rust (512/4k) and size: above 2TB 4k only, below 1TB 512 / check , between? - I'd opt for 4k as default -- and just where are defaults for BTRFS and XFS stored, only in the code / binary ?
Well I already said what the defaults are. But it's also stated in their mkfs man pages.
On the list of things I'm missing is a LVM-HOWTO with examples esp. for "Thin-Provisioning" sure info on that in one location is as rare as a egg-laying wool-giving pigs.
LMGTFY https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm... https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm...
BTRFS has still a way to go to reach ReiserFS for such cases. And for long-term external drives / sticks BTRFS is not mature enough, maybe in another 2 years.
Based on what data? I've been using Btrfs for externals for ~ 4 years.
XFS has gotten better in the last 6 years, but removing big trees, sync, create a new big tree, sync is still a good part slower. (15%-25% more time than ReiserFS, but that was 3times slower, 6years ago)
Well if you're going to go with a singular metric, then yes anyone can find disqualifying attributes for any file system. The question is the over all big picture fit. I don't have a use case for fast deletes actually committing to disk, the responsiveness of the command is sufficiently good and I care more about data integrity independent fs trees and essentially zero performance cost snapshots. But workflow wise I've leveraged ext4, XFS, Btrfs and LVM to meet the requirements at hand. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Chris Murphy wrote:
On Tue, Mar 17, 2015 at 4:39 PM, Linda Walsh
wrote: Greg Freemyer wrote:
Then you can see that many of his partitions are only 2GB of so.
Hey, I do similar, but with lvs: Home Data owc-aos-- 1.50t ... Home-2015.03.16-03.07.12 Data -wi-ao--- 840.00m Home-2015.03.17-03.07.03 Data swi-aos-- 1.50t Home 0.02 Home.diff Data -wi-ao--- 512.00g
[[Off topic but I'm wondering if those are LVM thin volume (snapshots)? Or are they the conventional ones? It seems like you have a good use case for thin volumes there. Not only are the snapshots faster, and independent (you can delete either the origin or destination LV, just like Btrfs snapshots/subvolumes), but you unlike Btrfs they can be thinly provisioned, almost totally obviating any need to resize a fs.
Thin snapshots were not around when I wrote snapper.pl. (neither was 'snapper'). It's a convenience.to allow me to retrieve recently changed files from my Window machine using the "Restore Previous Versions" feature. Actual backups are done using 'xfsdump'.
shrink = fstrim grow = Just start the thing out at 4x the size you think you'll ever need in its lifetime.]]
--- Eh... xfs doesn't shrink. And as was announced today, (AGAIN), btrfs isn't stable in latest kernel. So thin snaps w/XFS -- not quite there....whereas this script is pretty reliable.. checkpoints and can pick up a failed diff from day before before continuing with the current days.
If you assume most or all drive now are 512e (512 byte logical/4096 byte physical), you could just always use mkfs.xfs -s 4096. There is an infinitesimal negative of minimum _log_ IO size being 4096 bytes when the actual physical sector is 512 bytes; the inverse of that is not true though.
That's what the script ends up doing on 4096-byte disks, but /dev/sdb is still populated with 2T drives( 512 byte sectors), while /dev/sdc (system drive) uses 'quaint' 15K SAS drives.
There might be justification for -s 4096 becoming the default in the not too distant future.
--- I've been using 4096 as my FS-allocation size for >10 years, so using 4K for sectors isn't that big a change. I have run checks to see average file size/partition, and use that to determine the speculative allocation sizes: (T) mount point #files #blks+blksize averages (0) /boot: 64 48898 4K 764.5 blks/file (0) /tmp: 206 885722 4K 4300.1 blks/file (0) /var: 7808 885722 4K 113.9 blks/file (2) /Lmedia: 1233 51633897 4K 41877.1 blks/file (2) /backups: 5129 1889710900 4K 368437.0 blks/file (13) /backups/Media: 72482 2021618732 4K 27891.8 blks/file (25) /Media: 72485 2021920849 4K 27894.8 blks/file (26) /Nroot: 71351 2148774 4K 30.6 blks/file (28) /usr: 205114 2846057 4K 14.3 blks/file (58) /usr/share: 391953 4256786 4K 11.3 blks/file (193) /var/cache/squid: 593877 22716308 4K 38.7 blks/file (271) /local: 776408 199253318 4K 257.1 blks/file (313) /Share: 631405 212486572 4K 337.0 blks/file (697) /home: 6831949 252375423 4K 37.4 blks/file ---- number in 1st column are #secs since script started (it does a 'du' on all partitions in parallel). You can see none of them average less than 4K blks/file and several would benefit using even larger allocation sizes. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer composed on 2015-03-17 13:43 (UTC-0400):
Felix is a different kind of creature :)
He takes a TB or larger drive and puts a bunch of small partitions:
The one you're quoting from is 320G. :-) It came from the just retired HD that lead to my "smartctl: is this HD really OK?" thread.
== From one of Felix's posts == Device Boot Start End Blocks Id System /dev/sda1 63 80324 40131 6 FAT16 /dev/sda2 80325 578339 249007+ 1c Hidden W95 FAT32 (LBA) /dev/sda3 * 578340 1397654 409657+ 83 Linux /dev/sda4 1397655 625137344 311869845 5 Extended /dev/sda5 1397718 4466069 1534176 82 Linux swap / Solaris /dev/sda6 4466133 4482134 8001 1 FAT12 /dev/sda7 4482198 4996214 257008+ 6 FAT16 /dev/sda8 4996278 19743884 7373803+ 83 Linux /dev/sda9 19743948 28756349 4506201 83 Linux /dev/sda10 28756413 40226759 5735173+ 83 Linux /dev/sda11 40226823 78959474 19366326 83 Linux /dev/sda12 78959538 81417419 1228941 83 Linux /dev/sda13 81417483 91249199 4915858+ 83 Linux /dev/sda14 91249263 101080979 4915858+ 83 Linux /dev/sda15 101081043 110912759 4915858+ 83 Linux /dev/sda16 110912823 120744539 4915858+ 83 Linux /dev/sda17 120744603 130576319 4915858+ 83 Linux /dev/sda18 130576383 140408099 4915858+ 83 Linux /dev/sda19 140408163 150239879 4915858+ 83 Linux /dev/sda20 150239943 160071659 4915858+ 83 Linux /dev/sda21 160071723 171542069 5735173+ 83 Linux /dev/sda22 171542133 181373849 4915858+ 83 Linux /dev/sda23 252525798 262357514 4915858+ 83 Linux /dev/sda24 262357578 272189294 4915858+ 83 Linux /dev/sda25 272189358 282021074 4915858+ 83 Linux /dev/sda26 282021138 291852854 4915858+ 83 Linux /dev/sda27 291852918 301684634 4915858+ 83 Linux /dev/sda28 301684698 311516414 4915858+ 83 Linux /dev/sda29 311516478 624093119 156288321 83 Linux /dev/sda30 624093183 625137344 522081 e W95 FAT16 (LBA)
======
The defaults simply break in those conditions, so Felix has to concern himself with issues the rest of us never have come up.
If you look at the above you see he has a lot of partitions that start on a odd sector.
When I'm looking, I'm seeing a considerably less odd view than what that
fdisk -l output can show. My partitioner provides a quite different view,
readily available via log:
OS version : Linux 4.0.0 env TERM=linux root on big41
Disk 1 L-Geo from: LVM info at PSN 0x0000003e ACCEPTED as matching DLAT sector
Disk 1 forcing : cylinders from 38913 to 38914
L-Geo Disk 1 Cyl : 38914 H:255 S:63 Bps:512 Size : 0x25431582 = 305250 MiB
S-Geo Disk 1 Cyl : 38913 H:255 S:63 Bps:512 Size : 0x2542D6C1 = 305242 MiB
BIOS Int13 limit : 1024, I13X support needed beyond : 8032.5 MiB
MBR crc 054b4eb9 : 0x0c8ca699 = DFSee generic MBR, English messages, I13X
DFSee Linux 12.3 : Executing: fdisk -r-
Command timestamp : Monday 2015-03-02 05:00:12
+---+--+-----------------+--+--------+--------+-----------+----------------------------------------+---------+
|ID |Dr|Type, description|ux|Format |Related |VolumeLabel|LVM Vol,Part / GPT name | Size MiB|
+--
That is bad today. Typical modern partitioning tools will align all partitions to 1MB. Felix needs to adopt a 21st century partitioning mechanism.
Already done, intentionally to a limited extent, not fixin what ain't broke.
Then you can see that many of his partitions are only 2GB of so.
The preponderance of those are 4800.6MB. So far, only my 512n HDs
retain adherence to legacy partitioning. Here's an equivalent look
at a 2TB 512e on a machine used more for ordinary things, plus Windows,
and less for testing. ;-) :
OS version : Linux 3.12.36 env TERM=linux root on vizio
Disk 1 Warning : Geo size 0x2c9d74c1 smaller than size in sectors 0xe8e088b0,
Cylinder count recalculated and set to 243201.
Disk 1 L-Geo from: LVM DLAT at PSN 0x0000001f IGNORED, size < end of last partition
Disk 1 L-Geo from: MBR table, likely 1-MiB cylinders (like SSD or 4Kb sectors)
Disk 1 forcing : cylinders from 243201 to 1907730
Disk 1 forcing : heads from 255 to 64
Disk 1 forcing : sectors from 63 to 32
L-Geo Disk 1 Cyl :1907730 H: 64 S:32 Bps:512 Size : 0xE8E09000 = 1907730 MiB
S-Geo Disk 1 Cyl :243201 H:255 S:63 Bps:512 Size : 0xE8E074C1 = 1907726 MiB
BIOS Int13 limit : 1024, I13X support needed beyond : 1024.0 MiB
MBR crc 3669dc25 : 0xb16c291f = Windows 7, generic English
DFSee Linux 12.3 : Executing: fdisk -r-
Command timestamp : Thursday 2015-02-05 07:19:12
+---+--+-----------------+--+--------+--------+-----------+----------------------------------------+---------+
|ID |Dr|Type, description|ux|Format |Related |VolumeLabel|LVM Vol,Part / GPT name | Size MiB|
+--
participants (5)
-
Chris Murphy
-
Felix Miata
-
Greg Freemyer
-
Linda Walsh
-
Yamaban