[arch-general] GPT slower than MBR, although both are properly aligned?
Hi, I'm about to setup a new Arch box and wanted to use GPT instead of the (old) MBR partition scheme, just for the fun of it ;). I've read through the various articles in the wiki, but it seems that something strange is going on here. I'm about to install the system to a SSD (Kingston S100), therefore I also have to consider proper alignment. I've created the partition scheme with gdisk (alignment set to 2048 boundary, although I've tried it with different values (up to 8192), too), which basically looks like that: Number Start (sector) End (sector) Size Code Name 1 2048 264191 128.0 MiB 0700 Linux/Windows data 2 264192 31277198 14.8 GiB 0700 Linux/Windows data Take a look at the start sectors, they should be properly aligned to 2048, as 264192 is dividable by 2048. In order to check the proper alignment I've run hdparm -tT over both partitions, here are the results: /dev/sda1: Timing cached reads: 12026 MB in 2.00 seconds = 6017.15 MB/sec Timing buffered disk reads: 128 MB in 0.64 seconds = 201.56 MB/sec /dev/sda2: Timing cached reads: 12086 MB in 2.00 seconds = 6047.19 MB/sec Timing buffered disk reads: 278 MB in 3.02 seconds = 92.02 MB/sec Quite a huge discrepancy considering the fact that a SSD should have roughly the same speed everywhere. Well, after fiddling around with it a little bit, I've finally tried the same setup with the old MBR partition scheme, using fdisk, which gave me the following partition scheme: Device Boot Start End Blocks Id System /dev/sda1 2048 264191 131072 83 Linux /dev/sda2 264192 31277231 15506520 83 Linux So the partition scheme is the same, despite the fact that the second partition is a little bit bigger with MBR as there is no copy of the partition table. With the MBR partitions I get the following results using hdparm -tT in order to measure the speed: /dev/sda1: Timing cached reads: 11578 MB in 2.00 seconds = 5793.15 MB/sec Timing buffered disk reads: 128 MB in 0.63 seconds = 202.22 MB/sec /dev/sda2: Timing cached reads: 11896 MB in 2.00 seconds = 5952.79 MB/sec Timing buffered disk reads: 604 MB in 3.00 seconds = 201.16 MB/sec So, both partitions are, as to be expected, equal in speed. I'm quite astonished by these results, which confuse me totally. Is it possible that GPT is slower than MBR? Is there something wrong implemented within gdisk? Is there any explanation to that? Right now the only thing I can do to get full speed is to use MBR once again :(. Best regards, Karol Babioch
Hi again, well after looking at these numbers once again, I've tried the only thing left to do, which was to get the second partition ended in both partition schemes equally, which was 31277055. Although I loose more space at the end now, I get full speed on both partitions. So, it seems that not only the starting sectors have to be aligned, but also the ending ones, or at least the ending one of the last partition. It's just quite strange that it has worked with MBR so well, as 31277231 + 1 isn't a multiple of 2048? Therefore it must be something inside of the controller, which is responsible for the bad result. As already said I'm using a Kingston S100 (quite new), can anyone confirm this (either on this SSD, or on any other)? If this is a general issue the partition programs have to be updated once again ;). I'm waiting for any response before submitting this upstream. Best regards, Karol Babioch
You need to consider the structures that are written at the start of the partition, aligning only the partition start may not be enough (read, it is not the partition start you need to align). You need to consider the amount of data these structures use so the data part of the partition is aligned to flash sector boundaries. I have seen an explanation of this somewhere (for ext3 I think) and it was a little tricky, it needs a really good understanding of the filesystem you are going to use. I don't know if all vendors use the same sector/unit size, however for reading the alignment should not matter (which is what you are doing with hdparm -tT, the T part is only an indication of the read speed from cache so it's probably even less meaningful). It is the writes to disk that are affected if they are not aligned to the flash sectors so I guess there is something else going on there. I may be wrong though ... it would not the the first time :p -- Mauro Santos
Hi, Am 22.01.2011 23:29, schrieb Mauro Santos:
It is the writes to disk that are affected if they are not aligned to the flash sectors so I guess there is something else going on there.
No, you are right, for SSDs the alignment is only important for writing, as whole blocks of "sectors" get erased and have to be rewritten. At least I've read that somewhere. However, this doesn't explain my weird results, because hdparm -tT shouldn't write anything to the disk, should it? As I got it encrypted and lvm set on top of that with full speed, it seems that all is right so far, but this whole alignment stuff isn't as easy as it should be :(. Best regards, Karol Babioch
On 22-01-2011 22:49, Karol Babioch wrote:
No, you are right, for SSDs the alignment is only important for writing, as whole blocks of "sectors" get erased and have to be rewritten. At least I've read that somewhere.
However, this doesn't explain my weird results, because hdparm -tT shouldn't write anything to the disk, should it?
Hdparm shouldn't and doesn't write anything to disk as far as I know, that is why I said that something else must be interfering and gets you the results you presented. I have to agree with you that when using SSDs or newer drives with 4kB sectors but with 512B sectors emulation it is not very easy to get the alignment right. Maybe things will improve once the drives can report the true minimum sector size they use for writing, which I guess they should start doing soon or it will be a hidden bloody mess for everyone :p -- Mauro Santos
Hi, Am 23.01.2011 00:45, schrieb Mauro Santos:
Maybe things will improve once the drives can report the true minimum sector size they use for writing, which I guess they should start doing soon or it will be a hidden bloody mess for everyone :p
I guess the problem is that most (all?) of these devices report wrong values to the drivers (for compatibility reasons), so the only possible way to encounter this problem would be to provide a database with the OS/drivers, which seems to be quite odd :(. Hopefully this will change in the near future ;). Best regards, Karol Babioch
Hi! Maybe it's just me, but all your messages in this thread have a bad signature... Bye...Frank
On Sun, 2011-01-23 at 09:03 +0100, Frank Thieme wrote:
Hi!
Maybe it's just me, but all your messages in this thread have a bad signature...
Bye...Frank
Hello, I imported both Karol's signature and yours and Evo says the signature is valid. It just complains as I haven't signed nor set any trust on it but this is the right behavior. You have imported Karol's public key right? What does the signature of my email says? -- Guillaume
Hi, Am 23.01.2011 10:42, schrieb Guillaume ALAUX:
I imported both Karol's signature and yours and Evo says the signature is valid. It just complains as I haven't signed nor set any trust on it but this is the right behavior.
thanks for your positive reply, I already thought of a bad setup here :).
What does the signature of my email says?
Basically the same, your signature is valid, but not trusted. Best regards, Karol Babioch
Ah. But this is perfectly normal. I suggest the complaining ops reread the
PGP manual:
http://www.gnupg.org/gph/en/manual.html#AEN346
On Sun, 23 Jan 2011 17:07:15 +0700, Karol Babioch
Hi,
Am 23.01.2011 10:42, schrieb Guillaume ALAUX:
I imported both Karol's signature and yours and Evo says the signature is valid. It just complains as I haven't signed nor set any trust on it but this is the right behavior.
thanks for your positive reply, I already thought of a bad setup here :).
What does the signature of my email says?
Basically the same, your signature is valid, but not trusted.
Best regards, Karol Babioch
On 2011-01-23 at 11:07 +0100, Karol Babioch wrote:
Am 23.01.2011 10:42, schrieb Guillaume ALAUX:
I imported both Karol's signature and yours and Evo says the signature is valid. It just complains as I haven't signed nor set any trust on it but this is the right behavior.
thanks for your positive reply, I already thought of a bad setup here :).
Well, Mutt tells me that your key has expired:
gpg: Signature made Sun 23 Jan 2011 11:07:18 AM CET using RSA key ID 479F3215
gpg: Good signature from "Karol Babioch
What does the signature of my email says?
Basically the same, your signature is valid, but not trusted.
Same here with mutt 1.5.21-1 and gnupg 1.4.11-2:
gpg: Signature made Sun 23 Jan 2011 10:42:22 AM CET using DSA key ID 215B37AD
gpg: Good signature from "Guillaume ALAUX
On Sunday 23 January 2011 10:42:29 Guillaume ALAUX wrote:
I imported both Karol's signature and yours and Evo says the signature is valid. It just complains as I haven't signed nor set any trust on it but this is the right behavior.
Your's is "The signature is valid, but the key's validity is unknown.". That's different from Karol. As it is said before, his signing key is expired... Bye...Frank
Hi, Am 23.01.2011 12:45, schrieb Frank Thieme:
his signing key is expired...
Have you actually the latest version of my key? I've updated it quite a while ago, and plan to do so each year, as I've read somewhere that this is good praxis, just in case you loose your private key / revocation certificate. Best regards, Karol Babioch
Hi! On Sunday 23 January 2011 13:48:15 Karol Babioch wrote:
Have you actually the latest version of my key? I've updated it quite a while ago, and plan to do so each year, as I've read somewhere that this is good praxis, just in case you loose your private key / revocation certificate.
Ok, I manually fetched the key and it now expires 2011 instead of 2010. I don't know who is to blame for that ;) Bye...Frank
participants (6)
-
Benoit Myard
-
Frank Thieme
-
Guillaume ALAUX
-
Karol Babioch
-
Mauro Santos
-
Sebastian Schwarz