On Sat, Aug 30, 2008 at 10:02:10PM +0100, Simon Arlott wrote: > On 30/08/08 18:45, Matthew Wilcox wrote: > > On Sat, Aug 30, 2008 at 12:24:50PM -0500, James Bottomley wrote: > >> No, this is wrong. By mandated standards the manufacturers are allowed > >> to calculate MB by dividing by 10^6. This is a fiddle to allow them to > >> make their drives look slightly bigger. However, we want the printed > >> information to match that written on the drive, so in this printk, we > >> use the manufacturer standard for calculation (and then do everything > >> else in bytes so we don't have to bother with it ever again). > > It's unlikely to match what's on the drive, "1000204886016" isn't 1TB > by any standard. Hm. I bought a 500GB drive last year: sd 1:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB) 512 * 976773168 500107862016 512 * 976773168 / (1024 * 1024 * 1024) 465.76174163818359375000 If we report it as 465GB, we will get questions. Even pretending it's 1024 * 1000 * 1000 doesn't work: 512 * 976773168 / (1000 * 1000 * 1024) 488.38658400000000000000 I think we have to stick with dividing by multiples of 1000. It's what the drive manufacturers do (and I do understand their reasons for doing it). > This looks useful for testing this... do you have an updated version? Yes. http://git.kernel.org/?p=linux/kernel/git/willy/ata.git;a=shortlog;h=ata-ram > > 2. We should report in GB or TB when appropriate. The exact definition > > of 'appropriate' is going to vary from person to person. Might I > > suggest that we should report between two and four significant digits. > > eg 9543 MB is ok, 10543 MB should be 10 GB. > > I've gone with five digits, it switches to GB at ~98GB, and to TB > at ~98TB etc. Reasonable minds can certainly disagree on this one. I respectfully submit that reporting a 97415MB capacity is less useful than reporting a 97GB capacity. If you look at drive advertisements, they sell 1TB, 1.5TB, 80GB, 750GB, 360GB, ... we should be trying to match that. I'm a little dubious about trying to match the 1.5TB; I think 1500GB is close enough, but a 50GB drive shouldn't be reported as 50000MB. IMO, anyway. > > 3. I hate myself for saying this ... but maybe we should be using the > > horrific MiB/GiB/TiB instead of MB/GB/TB. > > Somehow this stuff got into net-tools (ifconfig) too, so I have a > patch to remove it from my systems. I understand why networking tools are particularly cautious about this. The line rate (eg 1Gbps) is 1000,000,000 bps, but the amount of traffic reported might well use either binary SI or decimal SI. Reporting the wrong one makes a 7% difference at the GB/GiB level, and that's the kind of amount that people can spend a week or more chasing. > > 4. I've been far too busy to write said patch. Simon, would you mind > > doing the honours? > > Sure, patch will follow this email... it can only go as far as 8192EB > and then there's not enough space to store more than 2^64 512-byte > sectors. I think it'll be a while before we get drives of that capacity. ATA is limited to 48 bits for the number of sectors, and while you can increase the sector size (4k is currently planned), that still doesn't bring you close. I suppose you could get ata_ram to have multiple drives and raid-0 them together, but you'd still need to allocate 2^13 of them. scsi_debug can probably go to the full 2^64 sectors. I haven't looked into it. > (And if you only modify drivers/scsi/sd.c, the kernel make system > won't recompile sd.o!) That sounds odd to me; what command are you using to rebuild? -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
