Re: disk partitioners vs disk with 2048 byte phusical sectors
- Date: Wed, 27 Sep 2017 13:14:41 -0400
- From: Gene Heskett <gheskett@xxxxxxxxxxx>
- Subject: Re: disk partitioners vs disk with 2048 byte phusical sectors
On Wednesday 27 September 2017 10:57:24 Roberto C. Sánchez wrote:
> On Wed, Sep 27, 2017 at 10:43:29AM -0400, Gene Heskett wrote:
> > On Wednesday 27 September 2017 08:46:30 Roberto C. Sánchez wrote:
> > > On Wed, Sep 27, 2017 at 08:42:08AM -0400, Gene Heskett wrote:
> > > > Do we have a disk partitioner that does understand a physical
> > > > sector size of any power of 2? gparted is out as this machine
> > > > does not yet have an x server installed, so I need a commandline
> > > > tool.
> > > >
> > > > Suggestions will be investigated, thank you.
> > >
> > > You don't mention which tool(s) you've already attempted, but have
> > > you looked at parted?
> > parted and fdisk, parted was I think mentioned in what you snipped,
> > but fdisk doesn't know how to even check alignment. (that I know of)
> > The last time I used fdisk I got write rates under 15 megs/second on
> > a sata-ii interface. I backed it up and fixed it with gparted and
> > its now doing about 120 megs/second.
> You mentioned gparted, which is a graphical version of parted. Since
> gparted worked for you, I figured the non-graphical parted might do
> what you need. Personally, I have had good success specifying
> arbitrary geometries with parted from the command-line.
> > Secondary question. On efi setups, how much blank space in front of
> > the 1st partition is needed for that stuff on a terrabyte drive? Or
> > is there even a rule of thumb about that?
> I thought only 1 MB was needed before the first partition, but I
> haven't messed with efi much.
> > Thanks Roberto.
> No problem.
Here's what I found that worked after wiping the part table out:
which made and wrote an empty dos part table.
Which made a 1G boot partition, an 8G destined to be swap, and the rest
destined to be an ext4 partition
then had apt install hdparm and busybox-static which hdparm needed.
root@rock64:~# hdparm -tT /dev/sda3
Timing cached reads: 1106 MB in 2.00 seconds = 552.98 MB/sec
Timing buffered disk reads: 354 MB in 3.00 seconds = 117.93 MB/sec
So the alignment must be ok if it gives those speeds. OTOH, they are read
speeds too. Thats where I am ATM.
The clue was in the sfdisk man page, it automatically works with the
disks native sector sizes when using the above syntax, where the comma
says start at the earliest AVAILABLE sector in each case.
And this is totally crazy, I had about 6 terminal-4.8 sessions going on
workspaces 1,2,3,5 & 6, each with multiple tabs, each tab logged into
one of my other machines, and they all just up and disappeared while I'm
writing this. And while it took about 10 minutes to restart the first 2
workspaces, (the command history was gone too) everything worked except
I had to accept a new ssh key from the rock64 I'm doing all this to. 94
days uptime here, might be time to reboot this old beast. Humm,
~/bin/mailwatcher, a bashy I wrote many years ago, which automates
feeding the fetchmail/procmail output into kmail, had also left w/o
saying goodby. I wonder what else will turn up missing.
The pi seems much happier now that it has an insane amount of rotating
swap, so thats next to setup on this rock64. Maybe the next person with
a similar problem will be helped by the above list of what I did.
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>