Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

1 GiB = 1024 * 1024 * 1024 bytes

1 GB = 1000 * 1000 * 1000 bytes

That is easy! I don't want to talk about this!

I have laptop which should have (according to seller) 1000 GB. That is 1000 000 000 000 bytes. It has even slightly bigger capacity according to fdisk - exactly 1000204886016 bytes.

That is aproximately 0.2 GB more than it should have!?

I didn't mind till now.

I am before some reinstallations and moving partitions without formatting and I would like back up whole drive including bootloader and everything before doing possibly dangerous things. I want to copy it up sector by sector using a command like following:

dd if=/dev/sda of=/dev/sdb

Now I want to buy a harddisk. I don't want to spend more money by buying bigger disk than I need. So it is enough to buy another 1000GB HDD?

Will it have the same size? If so why does the 1000GB disks have exactly this capacity. In oposite case is there a way to find out if disk is big enough before buying?

share|improve this question
    
The best place to check is the manufacturer's datasheet for the respective hard drive. It should state the capacity of the drive quite clearly. –  Breakthrough Mar 20 '13 at 20:30
    
The capacity is whatever it is. Generally it will be at least the advertised size, but it's unpredictable how much larger. It depends on how the manufacturer configured the drive in terms of platters, cylinders, sectors, spares, drive microcode, head parking areas, etc. –  Daniel R Hicks Jul 31 '13 at 23:36

5 Answers 5

Under the principle of "better safe than sorry", you're better off buying a bigger disk than you need; after all, you can always repave it and use it for something else once you're done doing dangerous things.

That said, if you really can't go that way, I'd recommend buying another disk of the same model as the one you're replacing, because exactly how many bytes a given "1TB" disk can hold is very likely to be manufacturer- and model-specific. Failing that, you'll need to either be able to run fdisk on your prospective backup disk, or find the result of someone else's having done so, in order to know for sure exactly how many bytes it can hold.

share|improve this answer
    
Even if it's the same model, it might be individual HDD-specific (It shouldn't be, but I don't know how hard drives are produced, so exact size might just be to within some tolerance. –  cpast Mar 20 '13 at 20:00

Not all hard drives with the same state capacity are identical size wise, although my experience tells me that most are for newer drives. (To mitigate problems with geometry I always used to locate the swap file at the end of the drive and recreate it - either a bit bigger or smaller so if it got corrupted during a DD it did not matter. I havn't needed to do this for a while, and the last 2 [ different age, different model 1 TB WD hard drives had identical geometry ] )

Instead of doing the backup using dd, why not write a large file (for example dd if=/dev/zero of=tmpfile.del bs=4096 count=X) and then delete it just prior to doing a tar -czf /new/drive/backup.tgz - which will then compress the drive and fit ? (creating the zero byte file and deleting it will make sure the space is actually compressible, regardless of what was there before, also using tar can actually be faster then dd because it writes less data - which is usually a slower process then compression, but YMMV)

share|improve this answer
    
That is great trick with writing zeros to large file and then deleting it! I like it very much. –  Robo Mar 20 '13 at 20:12
    
The trick with swap file is also good. But is safe only with MBR partition table. The GPT (Guid partition table) uses last sectors of disk to store the partition table. –  Robo Mar 20 '13 at 20:15
    
Interesting point. I didn't know that (I'm still coming to grips with GPT) –  davidgo Mar 20 '13 at 20:21

If the hard drive is not full you could do something like

gzip </dev/sda >/dev/sdb

But as davidgo suggested, writing a huge zero-filled file over the empty space might improve the compression if you have been deleting a lot of files. File systems usually only delete a file's inode and leave its contents on the drive until it needs to be overwritten by another file.

If the file system supports it, you could also try shrinking the partition that resides at the end of the drive by those extra 205 MB or whatever the difference would be. Then you would not have to copy over that extra space. You could look at the last 205 MB to see if there is anything meaningful or if it is just (mostly) filled with zeroes, in which case resizing the partition should be pretty safe.

tail -c 205MB </dev/sda | hd

This will generate a huge amount of output though if it's not empty.

share|improve this answer

I have laptop which should have (according to seller) 1000 GB. That is 1000 000 000 000 bytes. It has even slightly bigger capacity according to fdisk - exactly 1000204886016 bytes.

That is aproximately 0.2 GB more than it should have!?

That’s normal. Numbers like 1,000 or even 1,024 are only “nice, round” in specific scenarios like to us and computer software. When you manufacture a drive, it is extremely difficult to create it to be an exact number like that, especially for any sort of round media like hard-drives or DVDs because you are dealing with circles and of course when you are dealing with circles, thanks to π, you will almost never have integers, let alone “round numbers”.

As such, when you create a storage device, it will be rounded up to the nearest “block”. Whatever a block is depends on numerous factors and can cause it to have a little or even a lot of extra space (though always insignificant enough to not bother printing the excess all over the box in big, star-shaped stickers like “20% more space for FREE!!!”.

Even with non-circular media like flash-drives and memory-cards (as well as hard-drives of course), they still make sure to include a bunch of extra sectors for use as backups so that when a sector dies, the drive’s firmware can remap it to one of the “spares”. Whether these spares are visible to the user as “extra” space or not depends on the manufacturer (as cpast said, it can vary even from lot to lot of the same model). Some choose to let you see and use them, assuming that when a sector goes bad, it gets marked and the customer is not unhappy since they are still getting the full (and slightly more) capacity they paid for. Others hide the spare sectors and have the drive transparently remap on the fly so that the user never even knows there’s anything wrong. This is preferable (and most common these days) because it puts the onus of wear-leveling on the drive instead of on the OS or file-system. Even in this scenario, since there will usually be more spare sectors than needed (by their failure-calculation algorithms), they usually make the excess visible as well.

Will it have the same size? If so why does the 1000GB disks have exactly this capacity. In oposite [sic] case is there a way to find out if disk is big enough before buying?

There’s no way to know what the exact (down-to-the-byte/sector) capacity will be because it varies and is not part of the drive’s properties; it is a sort of “bonus”, so some will have more, others will have less.

Now I want to buy a harddisk. I don't want to spend more money by buying bigger disk than I need.

Of course, especially since getting a drive that’s bigger than 1TB would mean getting one that’s at least 1.5TB (there aren’t many, if any fine-grained divisions in between).

So it is enough to buy another 1000GB HDD?

It depends on how full the source drive is and the method of backing up. If you use normal backup programs (either file-level copying or drive-imaging), you can copy the source without issue if it contains no more than the capacity of the destination drive. If you clone it like you intend to do, then things could get tricky.

Some cloning tools are designed to account for variations in source and destination drives and have ways of dealing with it (e.g., offering a few choices and letting you decide which you want).

If you want to use something simple like dd, then it will be a little more trouble, but still fairly easy to handle:

  1. Get a (good) 1000GB drive, and find out the exact capacity to find the limit/line.
  2. Make sure that the amount of used space on the old drive is no more than the total size of the new drive.
  3. Do a defrag to move all the data the low-numbered sectors.
    • Of course this won’t guarantee that there’s no data over the line point because of gaps due to fragmentation. Therefore, you’ll want to use a disk-map-viewer to see if you have any files that are “out of bounds” and shuffle things around (e.g., delete or move to a spare drive) until you have nothing over the line.
  4. Use the count parameter of dd to limit the number of sectors to be copied to avoid going over.
  5. If necessary, copy back or re-download or whatever, any files that you removed from the old drive in step 3b.
share|improve this answer

Your basic problem is that the exact capacity is undefined.

If the drive has less than 1,000,000,000,000 bytes the seller is dirty but there are no promises beyond that point. Different internal designs will produce different values. You could even get a different capacity from identical hardware if they changed the number of spare sectors on the drive.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.