Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On 2020-09-11 07:21, David Wright wrote: On Thu 10 Sep 2020 at 16:15:05 (-0700), David Christensen wrote: On 2020-09-09 23:02, David wrote: On Thu, 10 Sep 2020 at 11:26, David Christensen wrote: On 2020-09-09 08:03, David Wright wrote: ... having been bitten by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561 2020-09-10 14:01:58 root@tinkywinky ~ # parted /dev/disk/by-id/ata-ST3300622AS_ unit s print free Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. I don't know what might have got your disk into this state, but I'm happy that you got it fixed. My own strategy would have been to use gdisk (my preferred partitioning program) to rewrite the backup table from the main table (command r for the recovery menu, then d). Thank you for the pointer. I will look at gdisk(8) the next time I have a need that I cannot figure out. I don't think the bug affects ordinary 512/512 disks, but only Advanced Format ones with larger block sizes, and then only if "they" also supply an erroneous I/O value, eg: Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes It's possible that this only occurs with USB disks, too. The partition can be 1MB aligned, but cryptsetup is fooled into setting the wrong alignment, eg: device-mapper: table: 254:1: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920 which was produced by this partition: /dev/sdb2 1302349824 1953521663 651171840 310.5G c W95 FAT32 (LBA) 1302349824/2048 635913.0 So, as my notes show, for the simple life, I always create partitions with 2MB alignment regardless of future use¹, and always add --align-payload 2048 to my cryptsetup commands. This option is benign because it's the default when the kernel doesn't supply a value. The man page says to prefer --offset, but as I know nothing about what any of these options actually do, I don't use --offset just because there's no default value given for it. (I suspect it may be the same as for --align-payload.) ¹ I don't worry about the initial BIOS boot partition. That sounds like some hard-won knowledge. I hope they fix the bug before I stumble into it. David
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Fri 11 Sep 2020 at 13:03:44 (+1000), David wrote: > On Fri, 11 Sep 2020 at 08:30, David Christensen > wrote: > > On 2020-09-10 09:44, David Wright wrote: > > > > I don't like parted particularly, and don't know what "free" does. > > > Can you elucidate? > > > > $ man parted | grep -i free > > > $ info --output=/dev/stdout --subnodes parted | grep -i free > > > I also am unable to find canonical documentation via RTFM, info, and > > STFW. GNU must have missed documenting it (?). > > # parted --help | grep -A 1 free > print [devices|free|list,all|NUMBER] display the partition table, > available devices, free space, all found partitions, or a particular > partition It looks as if that just got left out of the man page which, in other respects, has been condensed to yield $ /sbin/parted --help Cheers, David.
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Thu 10 Sep 2020 at 16:15:05 (-0700), David Christensen wrote: > On 2020-09-09 23:02, David wrote: > > On Thu, 10 Sep 2020 at 11:26, David Christensen > > wrote: > > > On 2020-09-09 08:03, David Wright wrote: > > > > > > ... having been bitten by > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561 > > > > > I have a 300 GB drive that has been causing me some confusion. Did I > > > elicity the bug when I partitioned the disk as follows? > > > > I have not read all relevant messages, but in case it helps you can > > check your exact device partition boundaries by running: > > > > parted /dev/disk/by-id/ata-ST3300622AS_ 'unit compact print > > free unit s print free unit b print free' > > That parted(8) incantation has issues, as does the disk: […] > This is how I invoke parted(8): > > 2020-09-10 14:01:58 root@tinkywinky ~ > # parted /dev/disk/by-id/ata-ST3300622AS_ unit s print free > Error: The backup GPT table is corrupt, but the primary appears OK, so > that will be used. > OK/Cancel? ok > Model: ATA ST3300622AS (scsi) > Disk /dev/sdb: 586072368s > Sector size (logical/physical): 512B/512B > Partition Table: gpt > Disk Flags: > > Number Start End SizeFile system Name Flags > 34s 2047s 2014s Free Space > 1 2048s 586072063s 586070016s ext2 > 586072064s 586072334s 271sFree Space I don't know what might have got your disk into this state, but I'm happy that you got it fixed. My own strategy would have been to use gdisk (my preferred partitioning program) to rewrite the backup table from the main table (command r for the recovery menu, then d). > Looking at the above information, my first partition starts at sector > 2048 and ends at sector 586072063 (inclusive). Both of these values > represent 1 MiB alignment, so it appears that the partition has not > been affected by bug 923561. I don't think the bug affects ordinary 512/512 disks, but only Advanced Format ones with larger block sizes, and then only if "they" also supply an erroneous I/O value, eg: Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes It's possible that this only occurs with USB disks, too. The partition can be 1MB aligned, but cryptsetup is fooled into setting the wrong alignment, eg: device-mapper: table: 254:1: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920 which was produced by this partition: /dev/sdb2 1302349824 1953521663 651171840 310.5G c W95 FAT32 (LBA) >>> 1302349824/2048 635913.0 >>> So, as my notes show, for the simple life, I always create partitions with 2MB alignment regardless of future use¹, and always add --align-payload 2048 to my cryptsetup commands. This option is benign because it's the default when the kernel doesn't supply a value. The man page says to prefer --offset, but as I know nothing about what any of these options actually do, I don't use --offset just because there's no default value given for it. (I suspect it may be the same as for --align-payload.) ¹ I don't worry about the initial BIOS boot partition. Cheers, David.
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On 2020-09-10 20:03, David wrote: On Fri, 11 Sep 2020 at 08:30, David Christensen... wrote: On 2020-09-10 09:44, David Wright wrote: I don't like parted particularly, and don't know what "free" does. Can you elucidate? $ man parted | grep -i free $ info --output=/dev/stdout --subnodes parted | grep -i free I also am unable to find canonical documentation via RTFM, info, and STFW. GNU must have missed documenting it (?). # parted --help | grep -A 1 free print [devices|free|list,all|NUMBER] display the partition table, available devices, free space, all found partitions, or a particular partition Thank you for finding that. :-) David
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Fri, 11 Sep 2020 at 09:15, David Christensen wrote: > On 2020-09-09 23:02, David wrote: > > parted /dev/disk/by-id/ata-ST3300622AS_ 'unit compact print > > free unit s print free unit b print free' > That parted(8) incantation has issues It works for me, but then again my disks are neither broken nor GPT.
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Fri, 11 Sep 2020 at 08:30, David Christensen wrote: > On 2020-09-10 09:44, David Wright wrote: > > I don't like parted particularly, and don't know what "free" does. > > Can you elucidate? > > $ man parted | grep -i free > > $ info --output=/dev/stdout --subnodes parted | grep -i free > I also am unable to find canonical documentation via RTFM, info, and > STFW. GNU must have missed documenting it (?). # parted --help | grep -A 1 free print [devices|free|list,all|NUMBER] display the partition table, available devices, free space, all found partitions, or a particular partition
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On 2020-09-09 23:02, David wrote: On Thu, 10 Sep 2020 at 11:26, David Christensen wrote: On 2020-09-09 08:03, David Wright wrote: ... having been bitten by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561 I have a 300 GB drive that has been causing me some confusion. Did I elicity the bug when I partitioned the disk as follows? I have not read all relevant messages, but in case it helps you can check your exact device partition boundaries by running: parted /dev/disk/by-id/ata-ST3300622AS_ 'unit compact print free unit s print free unit b print free' That parted(8) incantation has issues, as does the disk: 2020-09-10 14:00:52 root@tinkywinky ~ # parted /dev/disk/by-id/ata-ST3300622AS_ 'unit compact print free unit s print free unit b print free' Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. parted: invalid token: unit OK/Cancel? ok Model: ATA ST3300622AS (scsi) Disk /dev/sdb: 300GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 17.4kB 1049kB 1031kB Free Space 1 1049kB 300GB 300GB ext2 300GB 300GB 139kB Free Space This is how I invoke parted(8): 2020-09-10 14:01:58 root@tinkywinky ~ # parted /dev/disk/by-id/ata-ST3300622AS_ unit s print free Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. OK/Cancel? ok Model: ATA ST3300622AS (scsi) Disk /dev/sdb: 586072368s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 34s 2047s 2014s Free Space 1 2048s 586072063s 586070016s ext2 586072064s 586072334s 271sFree Space Looking at the above information, my first partition starts at sector 2048 and ends at sector 586072063 (inclusive). Both of these values represent 1 MiB alignment, so it appears that the partition has not been affected by bug 923561. David
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On 2020-09-10 09:44, David Wright wrote: On Thu 10 Sep 2020 at 16:02:59 (+1000), David wrote: On Thu, 10 Sep 2020 at 11:26, David Christensen wrote: ,,, I'm not sure what to ask for in terms of the encryption: See cryptsetup(8) with the 'isLuks' action and/or the '-v' option. For example, my daily driver: 2020-09-10 14:59:09 root@tinkywinky ~ # cat /etc/debian_version ; uname -a 9.13 Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64 GNU/Linux The boot partition (sda1) does not contain a LUKS volume. The root partition (sda3) does: 2020-09-10 15:25:51 root@tinkywinky ~ # cryptsetup isLuks -v /dev/sda1 Device /dev/sda1 is not a valid LUKS device. Command failed with code 22: Invalid argument 2020-09-10 15:25:55 root@tinkywinky ~ # echo $? 1 2020-09-10 15:25:56 root@tinkywinky ~ # cryptsetup isLuks -v /dev/sda3 Command successful. 2020-09-10 15:25:58 root@tinkywinky ~ # echo $? 0 I don't like parted particularly, and don't know what "free" does. Can you elucidate? $ man parted | grep -i free $ info --output=/dev/stdout --subnodes parted | grep -i free I also am unable to find canonical documentation via RTFM, info, and STFW. GNU must have missed documenting it (?). Briefly, if 'free' is provided after the 'print' option to parted(8), the displayed partition table shows unpartitioned free space. It is aware of sectors consumed by the partition scheme. For example, the system disk on my daily driver uses MBR: 2020-09-10 15:09:43 root@tinkywinky ~ # parted /dev/sda u s p Model: ATA INTEL SSDSC2CW06 (scsi) Disk /dev/sda: 117231408s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 2048s 1953791s1951744s primary ext4 boot 2 1953792s 3907583s1953792s primary 3 3907584s 27344895s 23437312s primary 4 27344896s 117229567s 89884672s primary 2020-09-10 15:09:46 root@tinkywinky ~ # parted /dev/sda u s p free Model: ATA INTEL SSDSC2CW06 (scsi) Disk /dev/sda: 117231408s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 63s 2047s 1985s Free Space 1 2048s 1953791s1951744s primary ext4 boot 2 1953792s3907583s1953792s primary 3 3907584s27344895s 23437312s primary 4 27344896s 117229567s 89884672s primary 117229568s 117231407s 1840s Free Space The 300 GB external disk uses GPT: 2020-09-10 15:19:20 root@tinkywinky ~ # parted -s /dev/sdb u s p Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. Model: ATA ST3300622AS (scsi) Disk /dev/sdb: 586072368s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 2048s 586072063s 586070016s ext2 4NF2P9SV 2020-09-10 15:23:14 root@tinkywinky ~ # parted -s /dev/sdb u s p free Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used. Model: ATA ST3300622AS (scsi) Disk /dev/sdb: 586072368s Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 34s 2047s 2014s Free Space 1 2048s 586072063s 586070016s ext2 4NF2P9SV 586072064s 586072334s 271sFree Space David
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Thu 10 Sep 2020 at 16:02:59 (+1000), David wrote: > On Thu, 10 Sep 2020 at 11:26, David Christensen > wrote: > > On 2020-09-09 08:03, David Wright wrote: > > > > ... having been bitten by > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561 > > > I have a 300 GB drive that has been causing me some confusion. Did I > > elicity the bug when I partitioned the disk as follows? > > I have not read all relevant messages, but in case it helps you can > check your exact device partition boundaries by running: My choice would be fdisk -l or gdisk -l for the partition table, but I'm not sure what to ask for in terms of the encryption: I don't know what options are available, nor how to interrogate for them after the event. But IIRC the alignment problem was logged in kern.log, so any output when the partition is unlocked and mounted might be useful. > parted /dev/disk/by-id/ata-ST3300622AS_ 'unit compact print > free unit s print free unit b print free' I don't like parted particularly, and don't know what "free" does. Can you elucidate? $ man parted | grep -i free $ info --output=/dev/stdout --subnodes parted | grep -i free Feel free to ask for help on this list -- just check that your GNU Parted is free software, covered by the GNU General Public License in the COPYING file. If not, write to the Free Software Foundation, the Free Translation Project. * 'COPYING.DOC' - the GNU Free Documentation Licence, the term under * 'INSTALL' -- how to compile and install Parted, and most other free * GNU Free Documentation License:: License for copying this manual File: parted.info, Node: GNU Free Documentation License, Up: Copying This Manual A.1 GNU Free Documentation License Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, works of the document must themselves be free in the same sense. license designed for free software. free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms grants a world-wide, royalty-free license, unlimited in duration, network protocols a complete Transparent copy of the Document, free The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new published (not as a draft) by the Free Software Foundation. If the choose any version ever published (not as a draft) by the Free under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; Free Documentation License''. recommend releasing these examples in parallel under your choice of free their use in free software. This manual is distributed under the GNU Free Documentation License, the Free Software Foundation; with no Invariant Sections, with no * FDL, GNU Free Documentation License: GNU Free Documentation License. $ Cheers, David.
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Thu, 10 Sep 2020 at 11:26, David Christensen wrote: > On 2020-09-09 08:03, David Wright wrote: > > ... having been bitten by > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561 > I have a 300 GB drive that has been causing me some confusion. Did I > elicity the bug when I partitioned the disk as follows? I have not read all relevant messages, but in case it helps you can check your exact device partition boundaries by running: parted /dev/disk/by-id/ata-ST3300622AS_ 'unit compact print free unit s print free unit b print free'
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On 2020-09-09 08:03, David Wright wrote: ... having been bitten by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561 I have a 300 GB drive that has been causing me some confusion. Did I elicity the bug when I partitioned the disk as follows? 2020-03-03 08:39:57 root@po ~ # parted /dev/disk/by-id/ata-ST3300622AS_ mkpart primary ext2 0% 100% Information: You may need to update /etc/fstab. David
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
David Wright writes: > On Wed 09 Sep 2020 at 08:53:20 (-0600), Joe Pfeiffer wrote: >> rhkra...@gmail.com writes: >> > On Tuesday, September 08, 2020 04:39:05 PM David Christensen wrote: >> >> Neither the string "2 MiB" nor the string "2 M" appear on page you have >> >> cited. >> > >> > That is correct, that's is what I have not found on that page. >> > >> >> Please provide a URL that advocates "start the first partition at 2 MIB" >> > >> > Maybe I misinterpreted what David Wright said in an email >> > responding to one of >> > my questions back in June. >> > >> > >> > Subject: Re: Advice on encrypted filesystem >> > Date: Friday, June 26, 2020, 09:25:49 AM >> > From: David Wright >> > To: debian-user@lists.debian.org >> > >> > ---< snip >--- >> > >> > If encrypting an entire disk, scramble the disk first, then partition. >> > If only encrypting a partition, partition the disk first. >> > *Alignments should be at least 2M (4096 x 512B sectors).* >> > Scramble any sensitive pre-existing contents: >> > >> > >> > I took that to mean that the first partition should start at 2 MiB. >> >> That doesn't follow -- 0 is 2 MiB-aligned (it's also aligned on whatever >> other size boundary you care to name, of course). > > Care to explain how you align the first partition with the start of the disk? Ah, of course.
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Wed 09 Sep 2020 at 08:53:20 (-0600), Joe Pfeiffer wrote: > rhkra...@gmail.com writes: > > On Tuesday, September 08, 2020 04:39:05 PM David Christensen wrote: > >> Neither the string "2 MiB" nor the string "2 M" appear on page you have > >> cited. > > > > That is correct, that's is what I have not found on that page. > > > >> Please provide a URL that advocates "start the first partition at 2 MIB" > > > > Maybe I misinterpreted what David Wright said in an email responding to one > > of > > my questions back in June. > > > > > > Subject: Re: Advice on encrypted filesystem > > Date: Friday, June 26, 2020, 09:25:49 AM > > From: David Wright > > To: debian-user@lists.debian.org > > > > ---< snip >--- > > > > If encrypting an entire disk, scramble the disk first, then partition. > > If only encrypting a partition, partition the disk first. > > *Alignments should be at least 2M (4096 x 512B sectors).* > > Scramble any sensitive pre-existing contents: > > > > > > I took that to mean that the first partition should start at 2 MiB. > > That doesn't follow -- 0 is 2 MiB-aligned (it's also aligned on whatever > other size boundary you care to name, of course). Care to explain how you align the first partition with the start of the disk? Cheers, David.
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
rhkra...@gmail.com writes: > On Tuesday, September 08, 2020 04:39:05 PM David Christensen wrote: >> Neither the string "2 MiB" nor the string "2 M" appear on page you have >> cited. > > That is correct, that's is what I have not found on that page. > >> Please provide a URL that advocates "start the first partition at 2 MIB" > > Maybe I misinterpreted what David Wright said in an email responding to one > of > my questions back in June. > > > Subject: Re: Advice on encrypted filesystem > Date: Friday, June 26, 2020, 09:25:49 AM > From: David Wright > To: debian-user@lists.debian.org > > ---< snip >--- > > If encrypting an entire disk, scramble the disk first, then partition. > If only encrypting a partition, partition the disk first. > *Alignments should be at least 2M (4096 x 512B sectors).* > Scramble any sensitive pre-existing contents: > > > I took that to mean that the first partition should start at 2 MiB. That doesn't follow -- 0 is 2 MiB-aligned (it's also aligned on whatever other size boundary you care to name, of course).
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Tue 08 Sep 2020 at 17:43:21 (-0400), rhkra...@gmail.com wrote: > On Tuesday, September 08, 2020 04:39:05 PM David Christensen wrote: > > Neither the string "2 MiB" nor the string "2 M" appear on page you have > > cited. > > That is correct, that's is what I have not found on that page. > > > Please provide a URL that advocates "start the first partition at 2 MIB" > > Maybe I misinterpreted what David Wright said in an email responding to one > of > my questions back in June. > > > Subject: Re: Advice on encrypted filesystem > Date: Friday, June 26, 2020, 09:25:49 AM > From: David Wright > To: debian-user@lists.debian.org > > ---< snip >--- > > If encrypting an entire disk, scramble the disk first, then partition. > If only encrypting a partition, partition the disk first. > *Alignments should be at least 2M (4096 x 512B sectors).* > Scramble any sensitive pre-existing contents: > > > I took that to mean that the first partition should start at 2 MiB. :) I'm flattered. OK, but those notes were introduced as *my* method for encrypting (spinning rust) disks. My 2MB alignment wouldn't apply to the first partition because I always start with a BIOS boot partition aligned (not that it really matters much) at the usual 1MB. With an ESP added too, I can boot the disk in either type of machine, BIOS or EFI. I see no point in not being generous with alignment as well as with partition sizes. Also, I always include --align-payload 2048 when creating encrypted partitions, having been bitten by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561 (2048 is not an override, but just the default made explicit.) Rationale: look back over just 2020 (if memory serves) for instances posted here of undersized ESP, /boot, /, and lack of anywhere to place Grub's core.img. Insufficient sizes get noticed; OTOH alignment problems sometimes get reported when they're diagnosed or logged, but are often ignored. Today's tools are very forgiving, and tend to just do the Right Thing. In my case, things worked well until I started adding encryption into the mix, and the logs reacted. Cheers, David.
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On 2020-09-08 14:43, rhkra...@gmail.com wrote: On Tuesday, September 08, 2020 04:39:05 PM David Christensen wrote: Neither the string "2 MiB" nor the string "2 M" appear on page you have cited. That is correct, that's is what I have not found on that page. Please provide a URL that advocates "start the first partition at 2 MIB" Maybe I misinterpreted what David Wright said in an email responding to one of my questions back in June. Subject: Re: Advice on encrypted filesystem Date: Friday, June 26, 2020, 09:25:49 AM From: David Wright To: debian-user@lists.debian.org ---< snip >--- If encrypting an entire disk, scramble the disk first, then partition. If only encrypting a partition, partition the disk first. *Alignments should be at least 2M (4096 x 512B sectors).* Scramble any sensitive pre-existing contents: I took that to mean that the first partition should start at 2 MiB. Perhaps David Wright can elaborate. David
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Tuesday, September 08, 2020 04:39:05 PM David Christensen wrote: > Neither the string "2 MiB" nor the string "2 M" appear on page you have > cited. That is correct, that's is what I have not found on that page. > Please provide a URL that advocates "start the first partition at 2 MIB" Maybe I misinterpreted what David Wright said in an email responding to one of my questions back in June. Subject: Re: Advice on encrypted filesystem Date: Friday, June 26, 2020, 09:25:49 AM From: David Wright To: debian-user@lists.debian.org ---< snip >--- If encrypting an entire disk, scramble the disk first, then partition. If only encrypting a partition, partition the disk first. *Alignments should be at least 2M (4096 x 512B sectors).* Scramble any sensitive pre-existing contents: I took that to mean that the first partition should start at 2 MiB.
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Tue, Sep 08, 2020 at 12:53:00PM -0400, rhkra...@gmail.com wrote: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes that leaves room for whatever may need to be at the beginning of the disk (like maybe the MBR, or LILO, or ???)? The current basic default is 1MByte. This is on a 512byte boundary, a 4kbyte boundary, and is relatively aligned with SSD erase blocks (typically 4MB or 16MB). It also is (IIRC) the windows default, so it's more likely that drive manufactuers have tested/optimized for that value than for any other. The default may be different in some cases, if the drive suggests a different alignment value. (E.g., on a RAID volume.) There's also simply no reason to choose a smaller value on a modern disk.
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Tuesday, September 08, 2020 12:53:00 PM rhkra...@gmail.com wrote: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes that leaves room for whatever may need to be at the beginning of the disk (like maybe the MBR, or LILO, or ???)? I've seen the advice to align partitions properly by starting them at a multiple of 4096 bytes, and I have (I think) a reasonable understanding of why (based on a sketch in the Wikipedia article on advanced partitioning). But then I see the advice to start the first partition at 2 MiB -- why not at some lower multiple of 4096 while leaving room for anything that may need to be at the very beginning of the disk? (I haven't found an explanation for that.) On 2020-09-08 09:56, rhkra...@gmail.com wrote: > Sorry, the Wikipedia article is Advanced Format: > > http://en.wikipedia.org/wiki/Advanced_Format Please use inline posting style or bottom posting style. Neither the string "2 MiB" nor the string "2 M" appear on page you have cited. Please provide a URL that advocates "start the first partition at 2 MIB" David
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
On Tue, 2020-09-08 at 12:53 -0400, rhkra...@gmail.com wrote: > Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes > that leaves room for whatever may need to be at the beginning of the disk > (like maybe the MBR, or LILO, or ???)? I believe it's for 'disks' based on solid state storage technology, NAND flash can have a large erase block size. -- Tixy
Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...
Sorry, the Wikipedia article is Advanced Format: http://en.wikipedia.org/wiki/Advanced_Format On Tuesday, September 08, 2020 12:53:00 PM rhkra...@gmail.com wrote: > Why start the first partition at 2 MIB, why not at any multiple of 4096 > bytes that leaves room for whatever may need to be at the beginning of the > disk (like maybe the MBR, or LILO, or ???)? > > I've seen the advice to align partitions properly by starting them at a > multiple of 4096 bytes, and I have (I think) a reasonable understanding of > why (based on a sketch in the Wikipedia article on advanced partitioning). > > But then I see the advice to start the first partition at 2 MiB -- why not > at some lower multiple of 4096 while leaving room for anything that may > need to be at the very beginning of the disk? (I haven't found an > explanation for that.)
