255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors45c45
/dev/sdc1 256 732563999 2930254976 c W95 FAT32 (LBA)
I bought a 3T drive which was prepartitioned with fat32.
I created a linux partition, but it looks a lot smaller:
38c38
< 42 heads, 63 sectors/track, 276858 cylinders, total 732566646 sectors
---
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors45c45
< /dev/sdc1 8191 732566645 2930233820 83 Linux
---
/dev/sdc1 256 732563999 2930254976 c W95 FAT32 (LBA)
The linux partition starts far latter and ends earlier. Am I interpreting that wrong, or is it fdisk(1)'s fault?
On 05/12/2017 12:43 PM, Charles T. Smith wrote:...
I bought a 3T drive which was prepartitioned with fat32.
...I created a linux partition, but it looks a lot smaller:
38c38
< 42 heads, 63 sectors/track, 276858 cylinders, total 732566646 sectors
---
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors45c45
< /dev/sdc1 8191 732566645 2930233820 83 Linux
---
/dev/sdc1 256 732563999 2930254976 c W95 FAT32 (LBA)
The linux partition starts far latter and ends earlier. Am I interpreting >> that wrong, or is it fdisk(1)'s fault?
You would do a lot better with a Live GPartEd CD but no Linux does not waste space ...
On Fri, 12 May 2017 13:02:57 -0700, Bobbie Sellers wrote:
On 05/12/2017 12:43 PM, Charles T. Smith wrote:....
I bought a 3T drive which was prepartitioned with fat32.
....I created a linux partition, but it looks a lot smaller:
38c38
< 42 heads, 63 sectors/track, 276858 cylinders, total 732566646 sectors
---
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors45c45
< /dev/sdc1 8191 732566645 2930233820 83 Linux
---
/dev/sdc1 256 732563999 2930254976 c W95 FAT32 (LBA) >>>The linux partition starts far latter and ends earlier. Am I interpreting >>> that wrong, or is it fdisk(1)'s fault?
You would do a lot better with a Live GPartEd CD but no Linux does not >> waste space ...
I'd like to understand why windows thinks it's okay to start a partition at block 256 but linux thinks you've got to throw away 8191 blocks. And
linux wants to leave a 21k block margin at the end of the sector that windows doesn't think is necessary.
Maybe the units are different? But the two fdisk outputs are identical except for the above differences.
I'd like to understand why windows thinks it's okay to start a partition at block 256 but linux thinks you've got to throw away 8191 blocks. AndAlignment changed during the years. Now it aligns on MiB boundaries,
linux wants to leave a 21k block margin at the end of the sector that windows doesn't think is necessary.
Maybe the units are different? But the two fdisk outputs are identical except for the above difference
I'd like to understand why windows thinks it's okay to start a partition at >> block 256 but linux thinks you've got to throw away 8191 blocks. And
linux wants to leave a 21k block margin at the end of the sector that windows
doesn't think is necessary.
Which Windows and which Linux!
On 2017-05-12 22:15, Charles T. Smith wrote:
Alignment changed during the years. Now it aligns on MiB boundaries, previously it did on 512 B sectors.
I'd like to understand why windows thinks it's okay to start a partition at >> block 256 but linux thinks you've got to throw away 8191 blocks. And
linux wants to leave a 21k block margin at the end of the sector that windows
doesn't think is necessary.
Maybe the units are different? But the two fdisk outputs are identical
except for the above difference
I bought a 3T drive which was prepartitioned with fat32.
I created a linux partition, but it looks a lot smaller:
38c38
< 42 heads, 63 sectors/track, 276858 cylinders, total 732566646 sectors
---
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors45c45
< /dev/sdc1 8191 732566645 2930233820 83 Linux
---
/dev/sdc1 256 732563999 2930254976 c W95 FAT32 (LBA)
The linux partition starts far latter and ends earlier. Am I interpreting that wrong, or is it fdisk(1)'s fault?
On 2017-05-12, Charles T. Smith <cts.private.yahoo@gmail.com> wrote:...
I bought a 3T drive which was prepartitioned with fat32.
I created a linux partition, but it looks a lot smaller:
38c38
< 42 heads, 63 sectors/track, 276858 cylinders, total 732566646 sectors
---
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors45c45
< /dev/sdc1 8191 732566645 2930233820 83 Linux
---
/dev/sdc1 256 732563999 2930254976 c W95 FAT32 (LBA)
I have no idea why you say the Linux one is much smaller. It is 2930
x10^6 bytes in size. while the W95 is the same.
On Fri, 12 May 2017 14:35:00 -0700, Bobbie Sellers wrote:
I'd like to understand why windows thinks it's okay to start a
partition at block 256 but linux thinks you've got to throw away
8191 blocks. And linux wants to leave a 21k block margin at the
end of the sector that windows doesn't think is necessary.
Which Windows and which Linux!
I don't have a windows machine. The disk was pre-formated with fat32
when I bought it today. My linux machine is ubuntu 14.04
(unfortunately).
I'm an old-fashioned guy, I don't need to be at the bleeding edge.
MBR is as much as I can handle, and with luck, I can stuck to under 4 primary partitions. In fact, I expect to format the 3T with a single partition - it's just for multigenerational 1Tb tarball backups.
Perhaps I should take my drive to work, where there are windows
machines and let windows partition it and then format it at home with
ext3 - or, you think that ext4 offers important advantages?
On 05/12/2017 01:15 PM, Charles T. Smith wrote:
On Fri, 12 May 2017 13:02:57 -0700, Bobbie Sellers wrote:
I'd like to understand why windows thinks it's okay to start a
partition at
block 256 but linux thinks you've got to throw away 8191 blocks. And
linux wants to leave a 21k block margin at the end of the sector that
windows
doesn't think is necessary.
Which Windows and which Linux!
Windows past version 7 uses UEFI coding and requires that you have several additional partitions. I have a HP Pavilion which came
with Windows 8.1 and it has about 4 special small partitions at the
beginning of the disk as well as a recovery partition of about 25 GiB
at the end of the disk.
This is why i talk about using a current GUI tool that lets
you see all the damned Windows necessary partitions.
Linux may be trying to clear the mess of the Windows partitions.
But if you were converting a disk from BIOS firmware to EFI firmware
then you need a special BIOS-Boot partition as well as an
EFI partition. But you have given no relevant information as to your
system and intent.
Hello Charles!
Friday May 12 2017 23:10, Charles T. Smith wrote to All:
Many current distros use it as a default and yes it does take a little more red tape space but there again FAT takes more along with the way it uses chunks of disk space where a lot can be unused.
In Linux it only takes up what is needed subject to the way you have set up the drive and that includes MSDOS or GPR partitioning and the hardware on
the drive itself. Then there is the SCSI controller at what you have it
set for.
No, it is not that straight forward but I would have thought that FAT of
any type is more wasteful.
Vince
On Fri, 12 May 2017 14:35:00 -0700, Bobbie Sellers wrote:
Well you are dealing with FAT 32 which does not support as many file attributes and permissions as Linux. As someone else mentions theI'd like to understand why windows thinks it's okay to start a partition at >>> block 256 but linux thinks you've got to throw away 8191 blocks. And
linux wants to leave a 21k block margin at the end of the sector that windows
doesn't think is necessary.
Which Windows and which Linux!
I don't have a windows machine. The disk was pre-formated with fat32 when I bought
it today. My linux machine is ubuntu 14.04 (unfortunately).
I'm an old-fashioned guy, I don't need to be at the bleeding edge. MBR is as much as I can handle, and with luck, I can stuck to under 4 primary partitions.
In fact, I expect to format the 3T with a single partition - it's just for multigenerational 1Tb tarball backups.
Perhaps I should take my drive to work, where there are windows machines and let
windows partition it and then format it at home with ext3 - or, you think that ext4
offers important advantages?
I'm an old-fashioned guy, I don't need to be at the bleeding edge.
MBR is as much as I can handle, and with luck, I can stuck to under 4
primary partitions. In fact, I expect to format the 3T with a single partition - it's just for multigenerational 1Tb tarball backups.
Perhaps I should take my drive to work, where there are windows
machines and let windows partition it and then format it at home with
ext3 - or, you think that ext4 offers important advantages?
I don't have a windows machine. The disk was pre-formated with fat32 when I bought
it today. My linux machine is ubuntu 14.04 (unfortunately).
I'm an old-fashioned guy, I don't need to be at the bleeding edge. MBR is as much as I can handle, and with luck, I can stuck to under 4 primary partitions.
In fact, I expect to format the 3T with a single partition - it's just for multigenerational 1Tb tarball backups.
Perhaps I should take my drive to work, where there are windows machines and let
windows partition it and then format it at home with ext3 - or, you think that ext4
offers important advantages?
On 2017-05-12, Charles T. Smith <cts.private.yahoo@gmail.com> wrote:
I bought a 3T drive which was prepartitioned with fat32.
Firstly, disk drive makers label their drives with the size in ordinary decimal numbers. Thus 3TB is 3 10^12 bytes, not 2^40= 3.3x10^12. Thus
3TB dive is what in computer speak would be about 2.7TB (which is what
Linux measures things in terms of)
On Fri, 12 May 2017 23:00:52 +0200, Carlos E. R. wrote:
On 2017-05-12 22:15, Charles T. Smith wrote:
Alignment changed during the years. Now it aligns on MiB boundaries,
I'd like to understand why windows thinks it's okay to start a partition at >>> block 256 but linux thinks you've got to throw away 8191 blocks. And
linux wants to leave a 21k block margin at the end of the sector that windows
doesn't think is necessary.
Maybe the units are different? But the two fdisk outputs are identical
except for the above difference
previously it did on 512 B sectors.
Okay 2^11 + 2^9 == 2^20. But why throw away that much data? That just leaves room for hackers to store stuff.
The *partition* is smaller after partitioning with linux's fdisk.
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 335his50336 bytes
Disk identifier: 0xeafbbd2f
Device Boot Start End Blocks Id System
/dev/sdc1 256 732563999 2930254976 c W95 FAT32 (LBA)
Well you are dealing with FAT 32 which does not support as many file attributes and permissions as Linux. As someone else mentions the
new standard in Linux is 1 megabyte boundaries. Actually the way the
hard disk is designated is wasting a lot of space because you might
expect 3 TB but you are getting something like 2.75 TB due to the
discrepancy between the advertising and the reality.
Okay 2^11 + 2^9 == 2^20. But why throw away that much data? That just leaves room for hackers to store stuff.
On 2017-05-13 00:22, William Unruh wrote:
On 2017-05-12, Charles T. Smith <cts.private.yahoo@gmail.com> wrote:
I bought a 3T drive which was prepartitioned with fat32.
Firstly, disk drive makers label their drives with the size in ordinary
decimal numbers. Thus 3TB is 3 10^12 bytes, not 2^40= 3.3x10^12. Thus
3TB dive is what in computer speak would be about 2.7TB (which is what
Linux measures things in terms of)
Nope :-)
"Thus 3TB dive is what in computer speak would be about 2.7TiB"
On 2017-05-13 00:58, Bobbie Sellers wrote:
Well you are dealing with FAT 32 which does not support as many file
attributes and permissions as Linux. As someone else mentions the
new standard in Linux is 1 megabyte boundaries. Actually the way the
hard disk is designated is wasting a lot of space because you might
expect 3 TB but you are getting something like 2.75 TB due to the
discrepancy between the advertising and the reality.
Wow!
No, not at all.
The disk advertises 3 TB, and it has 3 * 10E12 bytes. A bit more,
actually: what fdisk says is "3000.6 GB, 3000592982016 bytes". It has
exactly the advertised size and a bit more.
Your confusion comes from the computer people using binary units and multipliers not saying it, whereas the disk people don't.
The multiplier T, tera, is 1×10¹², or 1000⁴, the same for bytes, grams, metres, etc. Do not confuse with Ti, Tebi = 1024⁴
Take those 3000592982016 bytes bytes, and divide by
(1024*1024*1024*1024) and you get the familiar figure of 2.73, which is
not TB but TiB.
https://en.wikipedia.org/wiki/Tebibyte
Like it or not, those are the official numbers :-)
On Fri, 12 May 2017 18:13:48 -0400, Charles T. Smith <cts.private.yahoo@gmail.com> wrote:
Okay 2^11 + 2^9 == 2^20. But why throw away that much data? That just
leaves room for hackers to store stuff.
Just on this specific point. The reason for the change from cylinder to
1 MB alignment was to support various new drives, such as those with
a 4KB blocksize, those that have a 512B logical blocksize but have a
4KB physical blocksize, and ssd drives where the write block varies in
size, but always has an integer number of write blocks in a 1MB block.
...
On 2017-05-13, Carlos E. R. <robin_listas@es.invalid> wrote:
The disk advertises 3 TB, and it has 3 * 10E12 bytes. A bit more,
actually: what fdisk says is "3000.6 GB, 3000592982016 bytes". It has
exactly the advertised size and a bit more.
Computer people have used KMBT for 30 years to mean 2^{10,20,30,40}
The multiplier T, tera, is 1×10¹², or 1000⁴, the same for bytes, grams, >> metres, etc. Do not confuse with Ti, Tebi = 1024⁴
It is for grams, meters, etc. for memory etc they are powers of 2.
Windows past version 7 uses UEFI coding and requires that you have
several additional partitions.
I bought a 3T drive which was prepartitioned with fat32.
I created a linux partition, but it looks a lot smaller:
38c38
< 42 heads, 63 sectors/track, 276858 cylinders, total 732566646 sectors
---
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors45c45
< /dev/sdc1 8191 732566645 2930233820 83 Linux
---
/dev/sdc1 256 732563999 2930254976 c W95 FAT32 (LBA)
The linux partition starts far latter and ends earlier. Am I interpreting that wrong, or is it fdisk(1)'s fault?
On Saturday 13 May 2017 00:10, Charles T. Smith conveyed the following
to comp.os.linux.setup...
I'm an old-fashioned guy, I don't need to be at the bleeding edge.
MBR is as much as I can handle, and with luck, I can stuck to under 4
primary partitions. In fact, I expect to format the 3T with a single
partition - it's just for multigenerational 1Tb tarball backups.
I'm afraid that won't be possible.
If you want to make use of the full
capacity of a drive that's larger than 2 TiB ─ note: we're talking of binary capacity here, not decimal ─ then you're going to have to set up
a GUID partition table (GPT) on it
(and unformatted/unmounted) "BIOS partition" of about 3 MiB in size
right after the GPT header. This is so as to make sure that GRUB does
not overwrite the GPT partition table with its core.img stage.
As you have already been advised before, don't use fdisk, but use gdisk
or gparted instead.
And there are binary prefixes, which are distinct from SI prefixes.
Why some computer people refuse to use them to avoid confusion is
still a mystery to me.
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
And there are binary prefixes, which are distinct from SI prefixes.
Why some computer people refuse to use them to avoid confusion is
still a mystery to me.
We weren’t confused
and we don’t see why we should change.
Le 13/05/2017 à 01:28, Aragorn a écrit :
On Saturday 13 May 2017 00:10, Charles T. Smith conveyed the following
to comp.os.linux.setup...
I'm an old-fashioned guy, I don't need to be at the bleeding edge.
MBR is as much as I can handle, and with luck, I can stuck to under 4
primary partitions. In fact, I expect to format the 3T with a single
partition - it's just for multigenerational 1Tb tarball backups.
I'm afraid that won't be possible.
Indeed. Unless the disk is "Advanced Format" and uses a sector size
bigger than 512 bytes, the DOS/MBR partition scheme does not allow to
create partitions bigger that 2 TiB.
Le 13/05/2017 à 09:57, Richard Kettlewell a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
And there are binary prefixes, which are distinct from SI prefixes.
Why some computer people refuse to use them to avoid confusion is
still a mystery to me.
We weren’t confused
But you confuse the rest of the world.
Nope. While there is an attempt to use the TiB it has not really caught
on.
Eg,
info:0[unruh]>df -h
du -sh .
On 2017-05-12, Carlos E. R. <robin_listas@es.invalid> wrote:
On 2017-05-13 00:22, William Unruh wrote:
On 2017-05-12, Charles T. Smith <cts.private.yahoo@gmail.com> wrote:
I bought a 3T drive which was prepartitioned with fat32.
Firstly, disk drive makers label their drives with the size in ordinary
decimal numbers. Thus 3TB is 3 10^12 bytes, not 2^40= 3.3x10^12. Thus
3TB dive is what in computer speak would be about 2.7TB (which is what
Linux measures things in terms of)
Nope :-)
"Thus 3TB dive is what in computer speak would be about 2.7TiB"
Nope. While there is an attempt to use the TiB it has not really caught
on.
Bobbie Sellers <bliss@mouse-potato.com> writes:
Windows past version 7 uses UEFI coding and requires that you have
several additional partitions.
Windows doesn’t really care what boot protocol the machine uses (UEFI vs BIOS) or how the disk is partitioned (GPT or MBR).
On 2017-05-13, Carlos E. R. <robin_listas@es.invalid> wrote:
On 2017-05-13 00:58, Bobbie Sellers wrote:
Well you are dealing with FAT 32 which does not support as many file >>> attributes and permissions as Linux. As someone else mentions the
new standard in Linux is 1 megabyte boundaries. Actually the way the
hard disk is designated is wasting a lot of space because you might
expect 3 TB but you are getting something like 2.75 TB due to the
discrepancy between the advertising and the reality.
Wow!
No, not at all.
The disk advertises 3 TB, and it has 3 * 10E12 bytes. A bit more,
actually: what fdisk says is "3000.6 GB, 3000592982016 bytes". It has
exactly the advertised size and a bit more.
Computer people have used KMBT for 30 years to mean 2^{10,20,30,40}
Depite this the disk people use them to mean powers of 10 because it
made them seem bigger, not because they were pedantically using the SI definition of those units.
Your confusion comes from the computer people using binary units and
multipliers not saying it, whereas the disk people don't.
Why do they need to say it,since that nomenclature has been used for
years in the computer field. Disk people do not use it because they can confuse people by not using the standards of the computer field because
it makes the disks seem bigger.
"Charles T. Smith" <cts.private.yahoo@gmail.com> writes:
I bought a 3T drive which was prepartitioned with fat32.
I created a linux partition, but it looks a lot smaller:
38c38
< 42 heads, 63 sectors/track, 276858 cylinders, total 732566646 sectors
---
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors45c45
< /dev/sdc1 8191 732566645 2930233820 83 Linux
---
/dev/sdc1 256 732563999 2930254976 c W95 FAT32 (LBA)
The linux partition starts far latter and ends earlier. Am I interpreting >> that wrong, or is it fdisk(1)'s fault?
The partition end is easy to explain: it’s the last sector of the disk.
The partition start is more surprising; it’s fractionally below
32MB. Usually we would expect to see 1MB here (i.e. the same starting position that the origianl format used). fdisk takes account of optimal
I/O sizes in some of the alignment calculations, so what does the
following command produce?
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
Le 13/05/2017 à 09:57, Richard Kettlewell a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
And there are binary prefixes, which are distinct from SI prefixes.
Why some computer people refuse to use them to avoid confusion is
still a mystery to me.
We weren’t confused
But you confuse the rest of the world.
No, I think mendacious storage manufacturers confused the rest of the
world.
Using the old cylinder alignment causes a massive reduction in write performance.
When the write block does not align with the underlying
physical block size, each logical write requires 2 reads, merging of
the updated data with the two blocks read from the device, and then two writes. That's all handled by the drive controller, which is very slow compared to the main cpu.
Your confusion comes from the computer people using binary units and
multipliers not saying it, whereas the disk people don't.
Why do they need to say it,since that nomenclature has been used for
years in the computer field. Disk people do not use it because they can
confuse people by not using the standards of the computer field because
it makes the disks seem bigger.
The differences between the the two units is small, a 2%.
No, some mendacious computer people insist on confusing the rest of the world.
I'm an old-fashioned guy, I don't need to be at the bleeding edge. MBR is as >much as I can handle, and with luck, I can stuck to under 4 primary partitions.
In fact, I expect to format the 3T with a single partition - it's just for >multigenerational 1Tb tarball backups.
It appears in an OP's subsequent post that the disk actually has
4096-byte logical sectors ("4Kn" Advanced Format). So the DOS/MBR scheme
can be used to create a 3 TiB partition.
Le 13/05/2017 à 04:40, William Unruh a écrit :
On 2017-05-13, Carlos E. R. <robin_listas@es.invalid> wrote:
The disk advertises 3 TB, and it has 3 * 10E12 bytes. A bit more,
actually: what fdisk says is "3000.6 GB, 3000592982016 bytes". It has
exactly the advertised size and a bit more.
Computer people have used KMBT for 30 years to mean 2^{10,20,30,40}
And they have been wrong all this time. At least for a time they had the excuse that binary prefixes fitting their needs did not exist yet and
the difference between SI and binary prefixes was rather small and could
be unnoticed before the GB era. Now they don't have this excuse any more.
The multiplier T, tera, is 1×10¹², or 1000⁴, the same for bytes, grams,
metres, etc. Do not confuse with Ti, Tebi = 1024⁴
It is for grams, meters, etc. for memory etc they are powers of 2.
And there are binary prefixes, which are distinct from SI prefixes.
Why some computer people refuse to use them to avoid confusion is still
a mystery to me.
Le 13/05/2017 à 09:57, Richard Kettlewell a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
And there are binary prefixes, which are distinct from SI prefixes.
Why some computer people refuse to use them to avoid confusion is
still a mystery to me.
We weren’t confused
But you confuse the rest of the world.
and we don’t see why we should change.
Computer people against the rest of the world.
Le 13/05/2017 à 10:45, Carlos E. R. a écrit :
No, some mendacious computer people insist on confusing the rest of the
world.
I don' think they aim to confuse. As many people, they just selfishly
refuse to change their old bad habits and just expect the rest of the
world to adapt to them instead of the other way around.
The point that strikes me is that it would take them very little effort.
They are not asked to use decimal calculations instead of binary calculations, but just to add the "i" to show when they use binary calculations.
Le 13/05/2017 à 02:30, David W. Hodgins a écrit :
Using the old cylinder alignment causes a massive reduction in write
performance.
Note : this is because the usual (because maximum) logical sector per
track and head counts are 63 and 255, so the logical cylinder size is 63
* 255 which does not contain any power of 2.
The old cylinder alignment has another disadvantage with DOS/MBR
partition scheme : it only leaves 31 KiB before the first partition,
which is not always enough to write current GRUB's core image which has inflated due to functionnalities such as btrfs and LVM support.
When the write block does not align with the underlying
physical block size, each logical write requires 2 reads, merging of
the updated data with the two blocks read from the device, and then two
writes. That's all handled by the drive controller, which is very slow
compared to the main cpu.
I doubt this has anything to do with controller speed, at least on
spinning disks. Also, reading and writing two sectors instead of two
causes marginal penalty. Reading and writing at the same location on a spinning disk requires to wait for one complete lap, i.e. about 8 ms at
7200 RPM or 11 ms at 5400 RPM. This is just huge compared to the actual
read or write time at current throughputs.
On 2017-05-13, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
Le 13/05/2017 à 02:30, David W. Hodgins a écrit :
Using the old cylinder alignment causes a massive reduction in write
performance.
Note : this is because the usual (because maximum) logical sector per
track and head counts are 63 and 255, so the logical cylinder size is 63
* 255 which does not contain any power of 2.
It is C numbering, not Fortran.
On 2017-05-13, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
The point that strikes me is that it would take them very little effort.
They are not asked to use decimal calculations instead of binary
calculations, but just to add the "i" to show when they use binary
calculations.
It looks really ugly.
On 2017-05-13, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
Computer people against the rest of the world.
Yes, because the language arose in the context of computers.
Many many words have been coopted to mean technical things in a specific field. charm, beauty, up , down mean something very specific in the
context of particle physics, that they do not mean in other technical contexts.
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
It appears in an OP's subsequent post that the disk actually has
4096-byte logical sectors ("4Kn" Advanced Format). So the DOS/MBR scheme
can be used to create a 3 TiB partition.
I have never seen such a disk.
They do exist, but they appear in
homoepathic doses. I doubt that the OP is correct here. The line
"Sector Size" in an smartctl --all output of the disk in question
would help to bring in certainity.
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
Those binary prefixes were introduced long after the useage was
established, by pedants who could not tolerate the ambiguity of all
langauge, by the Sheldons of the computer world.
Most people are perfectly happy remembering that KMGT in computers is
powers of 2 while they indicate powers of 10 elsewehere,
On 2017-05-13 04:40, William Unruh wrote:
On 2017-05-13, Carlos E. R. <robin_listas@es.invalid> wrote:
On 2017-05-13 00:58, Bobbie Sellers wrote:
Well you are dealing with FAT 32 which does not support as many file >>>> attributes and permissions as Linux. As someone else mentions the
new standard in Linux is 1 megabyte boundaries. Actually the way the
hard disk is designated is wasting a lot of space because you might
expect 3 TB but you are getting something like 2.75 TB due to the
discrepancy between the advertising and the reality.
Wow!
No, not at all.
The disk advertises 3 TB, and it has 3 * 10E12 bytes. A bit more,
actually: what fdisk says is "3000.6 GB, 3000592982016 bytes". It has
exactly the advertised size and a bit more.
Computer people have used KMBT for 30 years to mean 2^{10,20,30,40}
Depite this the disk people use them to mean powers of 10 because it
made them seem bigger, not because they were pedantically using the SI
definition of those units.
Your confusion comes from the computer people using binary units and
multipliers not saying it, whereas the disk people don't.
Why do they need to say it,since that nomenclature has been used for
years in the computer field. Disk people do not use it because they can
confuse people by not using the standards of the computer field because
it makes the disks seem bigger.
The differences between the the two units is small, a 2%. Not much for
RAM, more for the bigger sizes of disks. Disk people used the correct
units and names; computer people invented new use for old units, and it
was wrong of them to do so.
Le 13/05/2017 à 18:03, William Unruh a écrit :
On 2017-05-13, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
Le 13/05/2017 à 02:30, David W. Hodgins a écrit :
Using the old cylinder alignment causes a massive reduction in write
performance.
Note : this is because the usual (because maximum) logical sector per
track and head counts are 63 and 255, so the logical cylinder size is 63 >>> * 255 which does not contain any power of 2.
It is C numbering, not Fortran.
What are you talking about ?
On 2017-05-13, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
Le 13/05/2017 à 09:57, Richard Kettlewell a écrit :
Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
And there are binary prefixes, which are distinct from SI prefixes.
Why some computer people refuse to use them to avoid confusion is
still a mystery to me.
We weren’t confused
But you confuse the rest of the world.
No they do not. The rest of the world does not care.
and we don’t see why we should change.
Computer people against the rest of the world.
Yes, because the language arose in the context of computers.
Many many words have been coopted to mean technical things in a specific field. charm, beauty, up , down mean something very specific in the
context of particle physics, that they do not mean in other technical contexts.
Do you rail against the world because the word sad now means an
depressed emotional state, rather than the feeling of fullness after a
good meal? Well I guess you should go around correcting everyone since
that the latter is what it used to mean before those stupid ignorant
people perverted the meaning.
Remember that KMGT in the sense of specific powers of 10were technical abreviations themselves and, as "official" SI designators, not
much older than their computer meaning.
The ones causing confusion are the disk people who, knowing full well
the computer meaning of those initials, went with the decimal version
because it gave them an advertising advantage, hiding greed behind
pedantry.
On 2017-05-13 18:59, Pascal Hambourg wrote:
Le 13/05/2017 à 18:03, William Unruh a écrit :
On 2017-05-13, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
Le 13/05/2017 à 02:30, David W. Hodgins a écrit :
Using the old cylinder alignment causes a massive reduction in write >>>>> performance.
Note : this is because the usual (because maximum) logical sector per
track and head counts are 63 and 255, so the logical cylinder size is 63 >>>> * 255 which does not contain any power of 2.
It is C numbering, not Fortran.
What are you talking about ?
That it starts at zero, not one. Ie 0 to 63, ie 64 sectors.
Well, the OP just quoted the output of fdisk :
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
After spending five minutes to find a system sufficiently ancient to
have an fdisk with this output format (Debian jessie is too new), I
can now confirm that the disks on this system report a sector size of
512 bytes.
So the OP has a really really seldomly found disk. One more reason to recommend staying with current defaults, as this reduces the chance of incompatibilities with future systems.
"Charles T. Smith" <cts.private.yahoo@gmail.com> wrote:
I'm an old-fashioned guy, I don't need to be at the bleeding edge. MBR is as >>much as I can handle, and with luck, I can stuck to under 4 primary partitions.
In fact, I expect to format the 3T with a single partition - it's just for >>multigenerational 1Tb tarball backups.
MBR maxes out at 2 TB. Good luck with that 3 T drive.
Greetings
Marc
On Sat, 13 May 2017 17:13:27 +0200, Marc Haber wrote:
"Charles T. Smith" <cts.private.yahoo@gmail.com> wrote:with having done the exact math, I'm a bit skeptical that I'll be
...
Le 14/05/2017 à 11:12, Marc Haber a écrit :
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
After spending five minutes to find a system sufficiently ancient to
have an fdisk with this output format (Debian jessie is too new), I
can now confirm that the disks on this system report a sector size of
512 bytes.
So the OP has a really really seldomly found disk. One more reason to
recommend staying with current defaults, as this reduces the chance of
incompatibilities with future systems.
I'd use a more recent version of fdisk which may handle 4Kn disks better.
(...)
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors >>>>> Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I'd use a more recent version of fdisk which may handle 4Kn disks better.
Hi. What is a 4Kn disk and how better?
Le 14/05/2017 à 12:31, Charles T. Smith a écrit :
(...)
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 45600 cylinders, total 732566646 sectors >>>>>> Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I'd use a more recent version of fdisk which may handle 4Kn disks better. >>Hi. What is a 4Kn disk and how better?
<https://en.wikipedia.org/wiki/Advanced_Format#4Kn>
Your disk should have the blue logo.
It's a disk with 4096-byte physical and logical (hence native) sectors instead of the traditional 512-byte sectors. 4096 bytes per physical
sector is better than traditional 512 bytes par sectors because it
increases the usable capacity by reducing metadata. 4096 bytes per
logical sector is better than 512e disks' 512 bytes per logical sector because it avoid alignment issues between higher level logical blocks
and physical sector boundaries.
On Sun, 14 May 2017 13:11:47 +0200, Pascal Hambourg wrote:(...)
<https://en.wikipedia.org/wiki/Advanced_Format#4Kn>
Your disk should have the blue logo.
I don't find the logo, though.
This looks like it (the data from the retailer was totally non-useful):
https://skinflint.co.uk/intenso-memory-board-3tb-6033511-a1586694.html
Le 14/05/2017 à 13:22, Charles T. Smith a écrit :
On Sun, 14 May 2017 13:11:47 +0200, Pascal Hambourg wrote:(...)
<https://en.wikipedia.org/wiki/Advanced_Format#4Kn>
Your disk should have the blue logo.
I don't find the logo, though.
This looks like it (the data from the retailer was totally non-useful):
https://skinflint.co.uk/intenso-memory-board-3tb-6033511-a1586694.html
It is a USB enclosure. The logo must be on the SATA disk inside.
(No, this is not an invitation to open the enclosure.)
On Sun, 14 May 2017 13:25:21 +0200, Pascal Hambourg wrote:
It has been reported that some BIOS firmwares cannot access LBA sector
addresses beyond 2^32 (i.e. 2 TiB with 512-byte sectors). Also, I would
not be surprised that old BIOS firmwares and boot loaders do not handle
correctly 4096-byte sectors.
Oh, you're saying that there really is a non-ignorable 2T limit, but
given 512b sectors? So, with 4K byte sectors, one would run into the
same limit at 16T? A sector-count limit?
Le 14/05/2017 à 13:24, Charles T. Smith a écrit :
On Sun, 14 May 2017 13:25:21 +0200, Pascal Hambourg wrote:
It has been reported that some BIOS firmwares cannot access LBA sector
addresses beyond 2^32 (i.e. 2 TiB with 512-byte sectors). Also, I would
not be surprised that old BIOS firmwares and boot loaders do not handle
correctly 4096-byte sectors.
Oh, you're saying that there really is a non-ignorable 2T limit, but
given 512b sectors? So, with 4K byte sectors, one would run into the
same limit at 16T? A sector-count limit?
Yes. A 2^32 (approximately 4 billion) sector count limit in the MBR/DOS partition scheme, in some BIOS firmwares, and maybe in other software
and filesystems.
On Sun, 14 May 2017 13:55:11 +0200, Pascal Hambourg wrote:
Le 14/05/2017 à 13:22, Charles T. Smith a écrit :
On Sun, 14 May 2017 13:11:47 +0200, Pascal Hambourg wrote:(...)
<https://en.wikipedia.org/wiki/Advanced_Format#4Kn>
Your disk should have the blue logo.
I don't find the logo, though.
This looks like it (the data from the retailer was totally non-useful):
https://skinflint.co.uk/intenso-memory-board-3tb-6033511-a1586694.html
It is a USB enclosure. The logo must be on the SATA disk inside.
(No, this is not an invitation to open the enclosure.)
;-)
Le 14/05/2017 à 12:30, Charles T. Smith a écrit :
On Sat, 13 May 2017 17:13:27 +0200, Marc Haber wrote:
MBR maxes out at 2 TB. Good luck with that 3 T drive.
(Note : with traditional 512-byte sectors)
To make a *bootable disk*, I presume is meant.
Booting is yet another story, involving the system firmware (BIOS or
UEFI in the PC world).
It has been reported that some BIOS firmwares cannot access LBA sector addresses beyond 2^32 (i.e. 2 TiB with 512-byte sectors). Also, I would
not be surprised that old BIOS firmwares and boot loaders do not handle correctly 4096-byte sectors.
On Sat, 13 May 2017 17:13:27 +0200, Marc Haber wrote:
MBR maxes out at 2 TB. Good luck with that 3 T drive.
To make a *bootable disk*, I presume is meant.
On Sat, 13 May 2017 17:13:27 +0200, Marc Haber wrote:
"Charles T. Smith" <cts.private.yahoo@gmail.com> wrote:
I'm an old-fashioned guy, I don't need to be at the bleeding edge. MBR is as
much as I can handle, and with luck, I can stuck to under 4 primary partitions.
In fact, I expect to format the 3T with a single partition - it's just for >>>multigenerational 1Tb tarball backups.
MBR maxes out at 2 TB. Good luck with that 3 T drive.
Greetings
Marc
To make a *bootable disk*, I presume is meant.
Mkfs has created a (almost) 3T FS in a (almost) 3T partition.
This disk is intended just for multigenerational backups (although,
with having done the exact math, I'm a bit skeptical that I'll be
able to get 3 generations of my 1T drive on it).
Le 14/05/2017 à 01:20, Carlos E. R. a écrit :
On 2017-05-13 18:59, Pascal Hambourg wrote:
Le 13/05/2017 à 18:03, William Unruh a écrit :
It is C numbering, not Fortran.
What are you talking about ?
That it starts at zero, not one. Ie 0 to 63, ie 64 sectors.
Sector numbering starts at 1 in CHS addressing. <https://en.wikipedia.org/wiki/Cylinder-head-sector#Sectors>
No, it's completely custom for your needs. What are your needs?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 150:17:25 |
| Calls: | 9,699 |
| Calls today: | 9 |
| Files: | 13,732 |
| Messages: | 6,178,917 |
| Posted today: | 1 |