Are there plans for 4096 byte H/D support in 32bit puppy?

[Aitch]

Big Terabyte hard drives are becoming more popular, and cheaper, but with them comes a new problem - 4096 byte sectors

It seems linux doesn't yet work with this setup

http://www.osnews.com/story/22872/Linux ... ard_Drives

Are we ready for this?

Is it just a need to update to a later version of grub, or is there another problem?

Aitch

[Aung]

Thanks for this one Aitch
When the author did his tests he gives results in real, user, and sys. I guess real would be from start to finish, can you tell me what user and sys times are. I bought a OCZ SSD to play with and went through this alignment thing with XP and diskpar.exe. with the bigger 4096-byte sectors.

"Some distros, like Ubuntu, use "parted", which has a very nice "--align optimal" option that will do the right thing."

Shock horror, I have just been into Gparted looking for align optimal, could not find it, but under partitions, imformation, sda1 starts at "first sector 63" which to me is not alligned.

"For /dev/sdc, I used fdisk the same as with sdd, but after creating the partition, I realigned it. I did this by entering expert mode ("x"), then setting the start sector ("b") to 64.
Once that was finished, I formatted both drives using the command "time mke2fs /dev/sdc1" (and sdd1)."

In doze XP the whole drive is aligned to 64 then the partitions are made with disk manager, the author created the partition first then aligned it then formated it. I dont know enough to argue about that one BUT when gparted formated the first partition to ext4 it has broken the alignment. Is this possible?
Me thinks we need a how to for this one. Aung

[Aung]

In cfdisk it says 'Sectors per Track: 63'. Should this be 'Sectors per Track: 64' to be aligned. Aung

[Aitch]

Aung

AFAIK the differences are the Sector SIZES, changed from 512kb to 4096kb to get over the 2Tb limit of 32bit filesystems

see

http://en.wikipedia.org/wiki/Cylinder-h ... or#Sectors

I wouldn't advise trying to change sector numbers as these determine the drives overall structure, and changing that will screw up your drive's fat table, in the boot sector

I believe 63 is correct - code begins at 0, so 0-63=64, OK?

A utility for modifying drives, is testdisk...though care is needed, as you can end up with a drive which is unrecognised by either linux or windoze

see also

http://osdir.com/ml/help-grub-gnu/2009-07/msg00003.html


NOTE: my original query was about 64 bit coded drive access in 32 bit puppy's grub - which I don't think reads 64bit coded xxTbyte drives

I've edited my original post to make this clearer, thanks

best info I've found so far

https://ata.wiki.kernel.org/index.php/A ... tor_issues

Aitch

[Aung]

Thanks again, I shall read up on all your links. Aung

[Aung]

Aitch, Yes I am off the track with 'sector per track 63' bit, understand that better now. But still worried about 'start sector 63', which is really sector 64 because the first sector is called '0' but should be really sector 65. It may be that Gparted didnt break what doze calls 'disk geometry' laid down by diskpar.exe but is, when makeing partitions, starting its first sector inside the 'hidden sectors' (doze calls them, for MBR and all that stuff I know nothing about)
Kirks fatdog 64 has fdisk but I could not enter expert mode to see whats in there I could play with. I guess I shall have to find a fdisk howto. Aung

from the author "For /dev/sdc, I used fdisk the same as with sdd, but after creating the partition, I realigned it. I did this by entering expert mode ("x"), then setting the start sector ("b") to 64."
Once that was finished, I formatted both drives using the command "time mke2fs /dev/sdc1" (and sdd1).

Here is a more detailed article about alignment from OCZ forum.
A disk's architecture is build using 64 sector tracks. Microsoft in it's archaic wisdom decided to use the first 63 sectors for the disk structure information when creating a partition using WinXP (as does most related partition editing tools), thereafter will create partitions starting at the beginning of sector 64 which is a great shame since the next track starts in just one more sector further on at the beginning of sector 65.

Starting the beginning of a partition at sector 64 (in this case on which to install Windows) has caused an extra IO for the drive mechanism while it attempts to write or read a 4k block of data spread across a barrier of two tracks at the boundary of sectors 64 & 65.
Look at it this way; the system uses the first 63 sectors for it's internal information (MBR, disk geometry, etc). Windows then writes data in blocks of 4096 bytes to the next available free sectors (starting at sector 64) the first 512bytes of data is written to that sector then all writing stops because the mechanism has reached the end of the current track, which then positions itself at the beginning of the next track and continues to write the remaining 3584bytes of the 4096bytes of data in one operation and will continue to do so until the next track boundary. If the mechanism could write the entire data into one track beginning at sector 65 then the drive would complete the task in one operation. With this misalignment flaw writing or reading data that crosses the track boundary takes two operations to accomplish, which now happens at every track boundary until the alignment is fixed.

[Aung]

Aitch, now I understand what you are on about. This is from GPT fdisk.

"In conjunction with the near-universal sector size of 512 bytes, the 32-bit LBA pointers used by MBR partitions impose a 2 TiB limit on disk and partition size. This limit, unlike the earlier 8 GiB limit of CHS, is not easily overcome by a simple extension to MBR; there simply isn't space left in the size allocated to MBR data structures. With 2 TiB drives available now and larger drives expected soon, this problem is a very serious one."

"EFI GUID Partition support works on both 32bit and 64bit platforms. You must include GPT support in kernel in order to use GPT. If you don't include GPT support in Linux kernelt, after rebooting the server, the file system will no longer be mountable or the GPT table will get corrupted."

For an exercise I used GPT fdisk to replace MBR on a Compact flash card in a SATA adaptor. (aligned to use 4096 b sectors like the new HD's are) then formated with 'mkfs.ext4 /dev/sda -b 4096' There was an error message from some sort of 'dump2fs' When I tried to install fat-dog 64, Uv. installer could not find the MBR (now GPT) and through up the super floopy wizard. Next I used Gparted to delete the 'mkfs.ext4' patition and made a new ext4 partition with Gparted (512 b sectors I guess). But could not set the boot flag 'cant manage flag' message. Will kernel support for GPT fdisk work in Puppy? Aung

[Aitch]

Yes, now you arrive at the same question I had, hence my post in 'cutting edge'
I await an answer from someone more knowledgeable

BarryK, amigo, SHS, technosaurus, Dennis McC, ttuuxxx......etc.... IDK

Aitch