posted on 2017-04-27 06:00
Disclaimer: This is a draft and waiting to be verified once I get around plugging all old disks in.
As of now, it mainly tries to specify the problem of disk sector size being report differently by linux on OS level and from
hdparm via the firmware, and wether
dd can really specify arbitrary blocksizes.
Getting it from the kernel via
fdisk did show different sizes from
hdparm when tested.
It's the only seemingly correct way to determine the sector sizes, since it queries the firmware on disk directly.
Getting it from the kernel via
fdisk should use that same info) did show different sizes from
hdparm -I when tested.
-i Display the identification info which the kernel drivers (IDE, libata) have stored from boot/config‐ uration time. This may differ from the current information obtainable directly from the drive itself with the -I option. The data returned may or may not be current, depending on activity since booting the system. For a more detailed interpretation of the identification info, refer to AT Attachment Interface for Disk Drives, ANSI ASC X3T9.2 working draft, revision 4a, April 19/93, and later editions. - I Request identification info directly from the drive, which is displayed in a new expanded format with considerably more detail than with the older -i option.
An overview on the information
hdparm gets, can be found here.
I did not find the actual block size in there, so my guess is the sizes are calculated from the information found in the drives registers.
-i shows pretty much a dump of the firware registers it seems, while
-I seems to do additional calculations to present more information in human-friendly form.
To overwrite the last 1mb of a disk via
dd, on a disk with 512b sectors this will do:
dd bs=512 if=/dev/zero of=/dev/sda count=2048 seek=$((`blockdev --getsz /dev/sda` - 2048))
bs is in bytes,
seek are blockcounts.
Questions for the future are:
blockdev --getbszprint in these cases?
Mind you, the numbers I saw earlier (2 years?) were with a dozen directly connected IDE and SATA drives, not with a raid controller in between, on disks of differenent manufacturers and sizes I had left over, and some showed in-kernel 512b even though they were 4k ones.
This really intrigues me, since the linux tools all seem to 'just work'.
dd in the past I ran into problems were I simply could not manually find data during forensic work on disks where its offset was calculated to be.
posted on 2014-09-29 12:15:40
When putting hardware RAID controller to use, you usually have to choose between the option in the post title.
Once the hardware-RAID-controller (HWR) has the data cached, which the operating system sent, it tells the OS to go on. (The OS is told the disk write is finished.)
OS -- HWR cache -- HDD / SSD 1. send data to write 2. data is cached 3. OS is told to go on 4. OS goes on 5. data is written to disk, when system load is low.
Only when the data has been written to disk, the OS is told so.
OS -- HWR cache -- HDD / SSD 1. send data to write 2. data is cached 3. data is written to disk 4. OS is told to go on 5. OS goes on
Test from the Proxmox wiki: (here)
Single SATA WD 400GB: 1360.17 3 x 15K rpm sas RAID5 with write-through: 159.03 (YES, only 159!) same as above but with write-back enabled: 3133.45
Use write-back on controllers with a battery backup unit (BBU) or a flash memory, depending on which functionality is available.
Adaptec's lower series cannot be equipped with neither, the 5xxx series can have one of each (or even both?). The 6xxx series doesn't need a BBU.
Take note, that BBU's need attention, whereas flash-based solutions are maintenance-free.
With SSD's however, you can forget about all this and just use write-through, since it's fast enough.
View posts from 2017-05, 2017-04, 2017-03, 2017-02, 2017-01, 2016-12, 2016-11, 2016-10, 2016-09, 2016-08, 2016-07, 2016-06, 2016-05, 2016-04, 2016-03, 2016-02, 2016-01, 2015-12, 2015-11, 2015-10, 2015-09, 2015-08, 2015-07, 2015-06, 2015-05, 2015-04, 2015-03, 2015-02, 2015-01, 2014-12, 2014-11, 2014-10, 2014-09, 2014-08, 2014-07, 2014-06, 2014-05, 2014-04, 2014-03, 2014-01, 2013-12, 2013-11, 2013-10