Discussion:
Partitioning SSD / Swap allocation
Add Reply
Tuxedo
2018-08-27 05:27:46 UTC
Reply
Permalink
Raw Message
Hello,

I'm installing Slackware 14.2 on a ThinkPad X280 and have two questions:

There is a SAMSUNG SSD type 970 EVO 2TB in the system, which I partitioned
as follows:

/dev/sda1 ext4 1.52TB
/dev/sda2 ext4 200GB
/dev/sda3 ntfs 100GB
/dev/sda4 libux-swap 8GB

I read something about alignement at
https://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/ssd-partition-alignment-tech-brief.pdf

Having just partitioned spinning drives in the past this has never been an
issue. Is it necessary to create free space somewehere between partitions to
prevent misalignment when using SSDs and if so, could it make any noticeable
difference in performance?

Also, the system has 8GB RAM. Does the rule of allocating swap of RAM x 2
still apply, so 16GB for 8GB physical RAM? For now I just kept it at 8GB as
I'm not sure if swap is even necessary in the first place?

Many thanks for any advise.

Tuxedo
Henrik Carlqvist
2018-08-27 05:47:31 UTC
Reply
Permalink
Raw Message
Post by Tuxedo
Also, the system has 8GB RAM. Does the rule of allocating swap of RAM x
2 still apply, so 16GB for 8GB physical RAM? For now I just kept it at
8GB as I'm not sure if swap is even necessary in the first place?
That rule of a thumb was from another era with another OS were the
computer RAM only was used as a "cache" for the swap area and the
available amount of memory to the OS was equal to the amount of allocated
swap.

With Linux the available amount of memory is equal to the sum of the
amount of RAM and the amount of swap. It is possible to run Linux
entirely without swap, but having some swap is in most cases still a good
idea. There are at least two reasons to have swap:

1) Most computers start a lot of processes which seldom are used. Unused
processes memory will end up in the swap area and their RAM can be used
for more useful things like disk cache.

2) If you at some occasion want to run many or big processes consuming
more memory than you have RAM swap will help you do that at the cost of
speed.

Still today even with rather expensive SSD disks disk memory is cheaper
than RAM memory so configuring some of that cheap disk area as swap is
usually a good idea.

regards Henrik
Peter Chant
2018-08-27 20:21:51 UTC
Reply
Permalink
Raw Message
Post by Henrik Carlqvist
With Linux the available amount of memory is equal to the sum of the
amount of RAM and the amount of swap. It is possible to run Linux
entirely without swap, but having some swap is in most cases still a good
1) Most computers start a lot of processes which seldom are used. Unused
processes memory will end up in the swap area and their RAM can be used
for more useful things like disk cache.
2) If you at some occasion want to run many or big processes consuming
more memory than you have RAM swap will help you do that at the cost of
speed.
Personally, especially with fast processors and slower disks (not so
much with SSD as you have here), I'd hope that I'd have enough RAM that
the swap was never hit. However, having some is insurance for the odd
case where it does occur.
Eli the Bearded
2018-08-27 06:19:53 UTC
Reply
Permalink
Raw Message
Post by Tuxedo
Having just partitioned spinning drives in the past this has never been an
issue. Is it necessary to create free space somewehere between partitions to
prevent misalignment when using SSDs and if so, could it make any noticeable
difference in performance?
I'd just skip a swap partition and use a swap file instead. In the past
swap partitions were often used to force the swap area to use a
particular part of the disk; somewhere close to the spindle has less
rotational latency than near the edge. With SSD there's no reason for
that anymore. Using one or more swapfiles makes it easier to adjust the
size of your swap over time, if needed.

dd if=/dev/zero of=/swap-a bs=1M count=$SIZE
mkswap /swap-a
swapon /swap-a

(Repeat with -b, -c, etc if desired.) All of these programs have good
manpages.

Starting with 1/2 to 1x RAM is probably fine.

Elijah
------
swapfiles are good for swap on cloud computers, too
Rich
2018-08-27 11:21:05 UTC
Reply
Permalink
Raw Message
Post by Eli the Bearded
Post by Tuxedo
Having just partitioned spinning drives in the past this has never been an
issue. Is it necessary to create free space somewehere between partitions to
prevent misalignment when using SSDs and if so, could it make any noticeable
difference in performance?
I'd just skip a swap partition and use a swap file instead. In the past
swap partitions were often used to force the swap area to use a
particular part of the disk; somewhere close to the spindle has less
rotational latency than near the edge.
Another reason was to force the swap area to be contigious on the disk
surface, but that reasoning also no longer applies to an SSD as well.
Post by Eli the Bearded
Using one or more swapfiles makes it easier to adjust the size of
your swap over time, if needed.
Very good point.

However, can Linux's hibernate subsystem hibernate into swap files, or
does it need an actual swap partition for hibernation purposes? If it
/needs/ a partition (and the OP wants to hibernate the laptop) then
this might call for some amount of swap partition space in order for
hibernation to operate.
Eli the Bearded
2018-08-27 19:42:02 UTC
Reply
Permalink
Raw Message
Post by Rich
However, can Linux's hibernate subsystem hibernate into swap files, or
does it need an actual swap partition for hibernation purposes?
It is possible, as in people have done it, but it is apparently
trickier.

https://docs.slackware.com/howtos:slackware_admin:swapfile_hibernation
Post by Rich
If it
/needs/ a partition (and the OP wants to hibernate the laptop) then
this might call for some amount of swap partition space in order for
hibernation to operate.
A reasonable point. In that case OP should have clearly understood that
swap needs to be at least as large as RAM. (Which maybe he did and I
misremember the question he asked about it.)

There's also uswsusp (userspace software suspend) which can write to an
arbitrary file, not swap. I've never tried it, but I have heard reports
of it working on Slackware.

Elijah
------
generally does not suspend his laptop
Tuxedo
2018-08-28 04:33:11 UTC
Reply
Permalink
Raw Message
Post by Eli the Bearded
Post by Rich
However, can Linux's hibernate subsystem hibernate into swap files, or
does it need an actual swap partition for hibernation purposes?
It is possible, as in people have done it, but it is apparently
trickier.
https://docs.slackware.com/howtos:slackware_admin:swapfile_hibernation
Post by Rich
If it
/needs/ a partition (and the OP wants to hibernate the laptop) then
this might call for some amount of swap partition space in order for
hibernation to operate.
A reasonable point. In that case OP should have clearly understood that
swap needs to be at least as large as RAM. (Which maybe he did and I
misremember the question he asked about it.)
There's also uswsusp (userspace software suspend) which can write to an
arbitrary file, not swap. I've never tried it, but I have heard reports
of it working on Slackware.
Elijah
------
generally does not suspend his laptop
Many thanks for the above and to everyone for their responses on this topic.

A swap file is a nice idea, but as you pointed out, it's more complex.

My system has 8GB RAM so I guess a 9GB swap partition should be fine for all
hibernation purposes.

I use LUKS on the Linux partition but without encrypting the swap space.

Tuxedo
Rich
2018-08-28 11:07:42 UTC
Reply
Permalink
Raw Message
Post by Tuxedo
A swap file is a nice idea, but as you pointed out, it's more
complex.
A swap file (for swap use only) is simple. Create a large file, run
"mkswap" on the file, run "swapon" on the file, gain extra swap. And
as someone pointed out in an earlier posting, swap files allow for easy
increases/decreases in the amount of allocated swap space.

What is more complex is utilizing a swap *file* to also perform laptop
style "save RAM to disk and then power down" (i.e., hibernation or
sleep). For that function, at least when using the kernel in-tree
hibernation drivers, a swap partition is *much* easier to utilize.

So your best route might be to allocate a partition that is slightly
larger than the maximum amount of RAM you ever expect to have in this
laptop. That makes setting up hibernation easy.

Then, should you determine you actually need more swap, add additional
swap via adding swap files.
Pascal Hambourg
2018-08-30 22:20:10 UTC
Reply
Permalink
Raw Message
Post by Rich
Post by Tuxedo
A swap file is a nice idea, but as you pointed out, it's more
complex.
A swap file (for swap use only) is simple.
No it's not. It's a hack. The kernel has to by-pass the filesystem layer
in order to access a swap file, but some filesystems may not support
this, such as btrfs because of its copy-on-write feature. A workaround
is to use a loop device instead of using the file directly, at the
expense of performance. Read man swapon(8) for details.
Eli the Bearded
2018-08-31 00:24:41 UTC
Reply
Permalink
Raw Message
Post by Pascal Hambourg
Post by Rich
A swap file (for swap use only) is simple.
No it's not. It's a hack. The kernel has to by-pass the filesystem layer
in order to access a swap file, but some filesystems may not support
this, such as btrfs because of its copy-on-write feature. A workaround
is to use a loop device instead of using the file directly, at the
expense of performance. Read man swapon(8) for details.
The btrfs filesystem was introduced in 2009. Using files for swap
predates that by a decade or two. I'm with Rick. Using swap files for
swap is easy. That some filesystems may be incompatible with swapfiles
is a limitation of those filesystems.

https://www.freebsd.org/cgi/man.cgi?query=swapon&apropos=0&sektion=0&manpath=Linux+Slackware+3.1&arch=default&format=html

SWAPON(8) Linux Programmer's Manual SWAPON(8)

NAME
swapon, swapoff - enable/disable devices and files for paging and swap-
ping

SYNOPSIS
/sbin/swapon [-h -V]
/sbin/swapon -a [-v]
/sbin/swapon [-v] [-p priority] specialfile ...
/sbin/swapoff [-h -V]
/sbin/swapoff -a
/sbin/swapoff specialfile ...

[...]

Linux 1.x 25 September 1995 SWAPON(8)

I know I was using swapfiles in the 1990s, on Solaris:

https://docs.oracle.com/cd/E19695-01/802-1930-1M/802-1930-1M.pdf

NAME swap − swap administrative interface

SYNOPSIS /usr/sbin/swap −a swapname [ swaplow ][ swaplen ]
/usr/sbin/swap −d swapname [ swaplow ]
/usr/sbin/swap −l
/usr/sbin/swap −s

AVAILABILITY SUNWcsu

DESCRIPTION swap provides a method of adding, deleting, and monitoring
the system swap areas used by the memory manager.

OPTIONS −a swapname Add the specified swap area. This option
can only be used by the super-user. swapname
is the name of the swap file: for example,
/dev/dsk/c0t0d0s1 or a regular file.

modified 1 Mar 1994

Between about 1999 and 2017 I did not ever find myself using swapfiles,
and only restarted because of "add swap to a cloud hosted VM" needs.

Elijah
------
has never used a swapfile for a hibernate
Pascal Hambourg
2018-08-31 22:01:26 UTC
Reply
Permalink
Raw Message
Post by Eli the Bearded
Post by Pascal Hambourg
Post by Rich
A swap file (for swap use only) is simple.
No it's not. It's a hack. The kernel has to by-pass the filesystem layer
in order to access a swap file, but some filesystems may not support
this, such as btrfs because of its copy-on-write feature. A workaround
is to use a loop device instead of using the file directly, at the
expense of performance. Read man swapon(8) for details.
The btrfs filesystem was introduced in 2009. Using files for swap
predates that by a decade or two.
So what ?
Post by Eli the Bearded
Using swap files for swap is easy.
Until you run into trouble because it does not work.
Post by Eli the Bearded
That some filesystems may be incompatible with swapfiles
is a limitation of those filesystems.
IMO it is rather a limitation of the Linux swap subsystem which was
primarily designed to use raw swap devices and was hacked to use swap
files in the same way.
The purpose of a filesystem is to provide an abstraction layer hiding
the underlying layout, but the kernel swap subsystem by-passes this
abstraction layer and accesses directly the physical blocks. This is why
I call it a hack. This is also one of the reasons why resume from
hibernation in a swap file is tricky.
The way the Linux kernel uses swap files relies on the assumption that
it exists a static mapping between files and underlying storage blocks.
This assumption remains valid with traditional filesystems such as the
ext* family, but not with less conventional filesystems. Btrfs is just
the most famous example. Another example is NILFS2, a log-structured
filesystem with versioning and continuous snapshotting features. Direct
access to underlying blocks is obviously not compatible with filesystem
features such as sparse files, preallocation, transparent compression,
data checksumming, copy-on-write, online defragmentation... I am not
even mentioning filesystems not based on block devices, such as JFFS2 or
UBIFS designed for use with MTD (raw NOR/NAND flash memory without a
translation layer found on embedded systems).
Linux is not Solaris.

Rich
2018-08-31 02:20:50 UTC
Reply
Permalink
Raw Message
Post by Pascal Hambourg
Post by Rich
Post by Tuxedo
A swap file is a nice idea, but as you pointed out, it's more complex.
A swap file (for swap use only) is simple.
No it's not. It's a hack.
Whoosh....

Simple (for the user). Given the context of the rest of the prior
posts this should have been obvious (the "for the user" part).
Post by Pascal Hambourg
The kernel has to by-pass the filesystem layer in order to access a
swap file, but some filesystems may not support this, such as btrfs
because of its copy-on-write feature. A workaround is to use a loop
device instead of using the file directly, at the expense of
performance. Read man swapon(8) for details.
Yes, underneath the hood it may very well be more complex. But from a
user's perspective, it's simple.

Make file.
mkswap the file.
swapon the file.
Pascal Hambourg
2018-08-30 22:13:01 UTC
Reply
Permalink
Raw Message
Post by Tuxedo
I use LUKS on the Linux partition but without encrypting the swap space.
Are you aware that the swap space may contain sensitive information and
should be encrypted ?
Tuxedo
2018-08-31 06:38:47 UTC
Reply
Permalink
Raw Message
Post by Pascal Hambourg
Post by Tuxedo
I use LUKS on the Linux partition but without encrypting the swap space.
Are you aware that the swap space may contain sensitive information and
should be encrypted ?
Yes. My partition setup is less than ideal for encryption. LUKS would be
better combined with LVM, which is what I will try next.

My first step was getting Slackware on the new machine and a test
installation of 14.2 64 on an SSD now appears to work fine.

Tuxedo
Eef Hartman
2018-08-27 11:36:23 UTC
Reply
Permalink
Raw Message
Post by Tuxedo
https://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/ssd-partition-alignment-tech-brief.pdf
Having just partitioned spinning drives in the past this has never
been an issue.
Most newer hard disks (especially 2 TB and beyond) actually use a 2 KB
internal blocksize, not the 512 bytes one of earlier ones.
I do _not_ know if that's true for modern SSD's too, but aligning on 2
KB boundaries never hurts.
And UEFI booting requires that the first partition leaves enough room
before it for the gpt partitition table, which normally means the first
partition has to start at least 64 "blocks" from the beginning. Modern
implementations of gdisk cq parted will start the first partition at
2 MB so both leaving enough space and using a 2 KB boundary for it.
Post by Tuxedo
Also, the system has 8GB RAM. Does the rule of allocating swap of
RAM x 2 still apply,
No, unless you want to run a program load of at least 2x the RAM.
But suspend/hibernate (in laptops) will need a swap area of "at least
RAM size" (as to be able to write the complete RAM in there), so swap
of "just a little bit over RAM" will then be required.
But I never ever used a swap of over 16 GB, even on systems (servers)
with 128 GB of RAM.
Eli the Bearded
2018-08-27 20:17:59 UTC
Reply
Permalink
Raw Message
Post by Eef Hartman
And UEFI booting requires that the first partition leaves enough room
before it for the gpt partitition table, which normally means the first
partition has to start at least 64 "blocks" from the beginning. Modern
implementations of gdisk cq parted will start the first partition at
2 MB so both leaving enough space and using a 2 KB boundary for it.
I recently had to configure a 1.5 TB partition on a RAID 1 pair of SSD
drives. gparted under Centos thought the "optimal" place to start the
first (and only in this case) partition was on the 1GB mark.

I went with it.

Elijah
------
that box is tight on RAM not disk anyway
Pascal Hambourg
2018-08-30 22:25:46 UTC
Reply
Permalink
Raw Message
Post by Eli the Bearded
I recently had to configure a 1.5 TB partition on a RAID 1 pair of SSD
drives. gparted under Centos thought the "optimal" place to start the
first (and only in this case) partition was on the 1GB mark.
Are you sure ? Wasn't it rather 1 MiB, the current standard for alignment ?
Eli the Bearded
2018-08-31 00:30:39 UTC
Reply
Permalink
Raw Message
Post by Pascal Hambourg
Post by Eli the Bearded
I recently had to configure a 1.5 TB partition on a RAID 1 pair of SSD
drives. gparted under Centos thought the "optimal" place to start the
first (and only in this case) partition was on the 1GB mark.
Are you sure ? Wasn't it rather 1 MiB, the current standard for alignment ?
Nope, not sure. So I checked:

(parted) print
Model: DELL PERC H730 Mini (scsi)
Disk /dev/sdb: 1600GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 1600GB 1600GB lvm

(parted)

I misremembered. :^)

Elijah
------
1596178488 1K-blocks, 10073424 Used, 1505017168 Available
Tuxedo
2018-08-28 05:16:12 UTC
Reply
Permalink
Raw Message
Post by Eef Hartman
Post by Tuxedo
https://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/ssd-partition-alignment-tech-brief.pdf
Having just partitioned spinning drives in the past this has never
been an issue.
Most newer hard disks (especially 2 TB and beyond) actually use a 2 KB
internal blocksize, not the 512 bytes one of earlier ones.
I do _not_ know if that's true for modern SSD's too, but aligning on 2
KB boundaries never hurts.
And UEFI booting requires that the first partition leaves enough room
before it for the gpt partitition table, which normally means the first
partition has to start at least 64 "blocks" from the beginning. Modern
implementations of gdisk cq parted will start the first partition at
2 MB so both leaving enough space and using a 2 KB boundary for it.
I'm not really sure exactly why it is needed but what unnalocated spaces do
you recommend I free up before, after and inbetween the partitions?

This is my initial current partition table:

/dev/sda1 ext4 1.52TiB <- user data
/dev/sda2 ext4 200GiB <- Slackware OS
/dev/sda3 ntfs 100GiB <- Windows
/dev/sda4 swap 8GiB <- Linix-swap

I use GParted's graphical application to set up the partitions and the above
fills up the SSD to the max:
https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-970-evo-nvme-m2-2tb-mz-v7e2t0bw/

Many thanks for any further tips.

Tuxedo
Post by Eef Hartman
Post by Tuxedo
Also, the system has 8GB RAM. Does the rule of allocating swap of
RAM x 2 still apply,
No, unless you want to run a program load of at least 2x the RAM.
But suspend/hibernate (in laptops) will need a swap area of "at least
RAM size" (as to be able to write the complete RAM in there), so swap
of "just a little bit over RAM" will then be required.
But I never ever used a swap of over 16 GB, even on systems (servers)
with 128 GB of RAM.
Eef Hartman
2018-08-28 06:34:53 UTC
Reply
Permalink
Raw Message
Post by Tuxedo
I'm not really sure exactly why it is needed but what unnalocated
spaces do you recommend I free up before, after and inbetween the
partitions?
GPartEd should normally do it OK:
about 1 MB before the first: start it on the 1 MB boundary.
All partitions should end on a 2 KB -1 blocknumber, so that NO space
is needed inbetween (the next partition will then automatically start
on that 2 KB boundary). At the end a little space is needed for the
secondary partition table, but, as I said, GPartEd should have used at
least the minimal alignment, which does all that.
If you run gdisk /dev/sda and it gives output like this:
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.

then it should be OK. With the "p" command you can print your partition
layout (and with "q" you can leave it again when you don't want to
make changes).
This is the one from my (non-bootable 2nd) 2 TB disk, which has a
single partition:
1 2048 3762778111 1.8 TiB 0700 primary
and you see it starts at sector 2048 and ends at ...11, which is a
multiple of 4 minus 1 (btw this disk still uses a local sector size
of 512 bytes).
Post by Tuxedo
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
so the partition does not use all of the disk yet, but satisfies all
UEFI requirements, even though this isn't my boot disk.
Tuxedo
2018-08-29 08:08:17 UTC
Reply
Permalink
Raw Message
Post by Eef Hartman
Post by Tuxedo
I'm not really sure exactly why it is needed but what unnalocated
spaces do you recommend I free up before, after and inbetween the
partitions?
about 1 MB before the first: start it on the 1 MB boundary.
All partitions should end on a 2 KB -1 blocknumber, so that NO space
is needed inbetween (the next partition will then automatically start
on that 2 KB boundary). At the end a little space is needed for the
secondary partition table, but, as I said, GPartEd should have used at
least the minimal alignment, which does all that.
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
then it should be OK. With the "p" command you can print your partition
layout (and with "q" you can leave it again when you don't want to
make changes).
This is the one from my (non-bootable 2nd) 2 TB disk, which has a
1 2048 3762778111 1.8 TiB 0700 primary
and you see it starts at sector 2048 and ends at ...11, which is a
multiple of 4 minus 1 (btw this disk still uses a local sector size
of 512 bytes).
Post by Tuxedo
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
so the partition does not use all of the disk yet, but satisfies all
UEFI requirements, even though this isn't my boot disk.
Thanks for the detail info. I have some problems running gdisk for some
reason on the GParted live USB media.

And when using GParted's partitioning tool, to create unnallocated space of
for example 1MB before the first partition, the tool fires up a warning:

---------------------------------------
Moving a partition might cause your operating system to fail to boot.

You have queued an operation to move the start sector of partition
/dev/nvme01p1. Failure to boot is most likely to occure if you move the
GNU/Linux partition containing /boot, or if you move the Windows partition
C:.
---------------------------------------

So I did not proceed with the above.

Anyway, perhaps GParted's graphical GUI tool takes care of the correct
partitioning spacing automatically?

This is the Device infomation displayed by GParted:

Size: 1.82 TiB

Partition table: msdos
Heads: 255
Sectors/track: 63
Cylinders: 243201
Total sectors: 3907029168
Secor size: 512

/dev/nvmeOn1p1 ext4 data 1.52 TiB
/dev/nvmeOn1p2 ext4 slackware 200 GiB
/dev/nvmeOn1p3 ntfs windows 100 GiB
/dev/nvmeOn1p4 linux-swap swap 8GB

As I originally set up the four partitions, the first sector starts at 2048
and ends at 3261106175

The second partition starts at 3261106176 and ends at 3680536575.

The third starts at 3680536576 and ends at 3890251775.

The fourth partition starts at 3890251776 and ends at 3907028991

Is this a good and workable partitioning setup? So far the partitions are
empty and no OS or data exists on any of them, so they can be recreated in
any way that may be better.

Swap as said is needed for suspension or hibernation. The built-in memory is
8GB and it will never change because it's a non-exchangable RAM soldered
onto the mainboard.

I always use LILO via the MBR for the OS selection prompt rather than
booting directly from a partition or using GRUB.

Many thanks for any advise.

Tuxedo
Pascal Hambourg
2018-08-30 22:24:43 UTC
Reply
Permalink
Raw Message
Post by Eef Hartman
Most newer hard disks (especially 2 TB and beyond) actually use a 2 KB
internal blocksize, not the 512 bytes one of earlier ones.
Isn't it rather 4 KiB ?
Post by Eef Hartman
I do _not_ know if that's true for modern SSD's too, but aligning on 2
KB boundaries never hurts.
Alignment on SSDs should be done on write block and erase block
boundaries, whose sizes vary. This is why a 1 MiB boundary is widely
adopted.
Post by Eef Hartman
And UEFI booting requires that the first partition leaves enough room
before it for the gpt partitition table
UEFI booting does not require anything of this sort. It does not even
require a GPT partition table.
Eef Hartman
2018-08-31 04:23:18 UTC
Reply
Permalink
Raw Message
Post by Pascal Hambourg
Post by Eef Hartman
Most newer hard disks (especially 2 TB and beyond) actually use a 2 KB
internal blocksize, not the 512 bytes one of earlier ones.
Isn't it rather 4 KiB ?
On _my_ disks the alignment seems to be 2 KB (cq 2kiB, the CAPITAL K
already implies 1024 as the ISO prefix for 1000 is with lower case k).
This is from two (identical, Toshiba 2 TB, but one is internal and the
other one EXternal) disks, formatted with parted:
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-byte boundaries
Total free space is 2017 sectors (1008.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 2048 3907029131 1.8 TiB 8300 Linux
cq.
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 32-sector boundaries
Total free space is 1921 sectors (960.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 1952 3907029131 1.8 TiB 8300 Linux

PS: on both disks the "end sector" has been modified afterwards to
just below the maximum usable sector as to not waste space: they are
not bootable anyway and I don't have a UEFI capable system, but the
starting sector has been selected by parted and gdisk reports a gpt
partition table present.

I don't remember the exact creation commands, it's been some time ago,
but I did notice that they weren't formatted the same way.

PS2: it's gdisk too that changed the partition type to 8300
Rich
2018-08-31 04:56:48 UTC
Reply
Permalink
Raw Message
Post by Eef Hartman
Post by Pascal Hambourg
Post by Eef Hartman
Most newer hard disks (especially 2 TB and beyond) actually use a 2 KB
internal blocksize, not the 512 bytes one of earlier ones.
Isn't it rather 4 KiB ?
On _my_ disks the alignment seems to be 2 KB (cq 2kiB, the CAPITAL K
already implies 1024 as the ISO prefix for 1000 is with lower case k).
Number Start (sector) End (sector) Size Code Name
1 2048 3907029131 1.8 TiB 8300 Linux
You do realize that the 2048 number is in units of "sectors" right? So
it is not "2 KB" (as in kilo-byte) but "2 KS" (as in kilo-sectors).
The number of "bytes" in 2048 sectors will depend upon whether the disk
is a 512 byte sector disk or a 4096 byte sector disk.

fdisk -l will give you the logical and physical sector sizes of a disk.

Here is a portion of fdisk -l output on a disk I have that is 512 byte sectors:

Disk /dev/sdd: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
^^^^^^^^^
And here is fdisk -l on a 4KB (as in kilo-byte) sector disk:

Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
^^^^^^^^^^
A partition with 2048 KS (kilo-sectors) alignment is either:

2048 * 512 = 1048576 bytes or 1MB alignment
or
2048 * 4096 = 8388608 bytes or 8MB alignment
Eef Hartman
2018-08-31 06:30:53 UTC
Reply
Permalink
Raw Message
Post by Rich
You do realize that the 2048 number is in units of "sectors" right?
You're right, so my partitions start at around 1 MB.

I also read-up about Advanced Formatting and indeed those disks are
using a 4KB sector size, so my previous msgs about 2 KB should be
corrected.
Loading...