DISKSCAN(1)

πŸ“¦
version 0.21 Β· 3 versions
, in debian trixie, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– DISKSCAN β€” the diskscan(1) page, but make it make sense πŸ’–

okay bestie, so you know how your disk can start acting sus before it fully gives up the ghost? this is the tool that catches that. it's diskscan, from the User Commands section of the manual, and it's here to do a lil health check on your drive before things get tragic. 🩺✨


🌸 NAME 🌸

diskscan β€” scan a disk for failed and near failure sectors


πŸŽ€ SYNOPSIS πŸŽ€

diskscan [options...] block_device

✨ DESCRIPTION ✨

so here's the tea: diskscan is built to check a disk and find any bad sectors that are already there, plus assess whether there are any sectors that are lowkey in the process of going bad. πŸ’€ and the best part? the whole operation is all read-only β€” it can cause no direct damage to the data on your disk. no cap. your data is safe, we're just looking. πŸ‘€

the way it works is it reads the entire block device and notes how long it took to read a block. when there's an error it gets noted immediately, and also when there's a higher latency to read a block. then it gives you a histogram of the block latency times so you can assess the health of the disk. it's giving doctor's report but for your drive. 🫢

the output will show any serious errors or very high latency, and it'll also emit a histogram at the end of the run, in this form:

I: Validating path /dev/sdg
I: Opened disk /dev/sdg
I: Scanning disk /dev/sdg
Access time histogram:
       1: 0
      10: 0
     100: 0
     500: 120
    1000: 0
    2000: 1
    3000: 0
    4000: 0
    5000: 0
    6000: 0
    7000: 0
    8000: 0
    9000: 0
   10000: 0
   15000: 0
   20000: 0
   25000: 0
   30000: 0
above that: 0
I: Closed disk /dev/sdg

so what does that mean? it means all I/Os in this case were between 100 and 600 msec, and there were 120 chunks being read. currently these chunks are 1MB in size. icon behavior from that disk honestly. πŸ’…


πŸ‘‘ OPTIONS πŸ‘‘

  • -v, --verbose β€” display verbose information from the workings of the scan. use it multiple times for increased verbosity. yes bestie, stack it, it's multiplicative energy. πŸ”₯
  • -f, --fix β€” attempt to fix areas that are nearing failure. this should only be attempted on an unmounted block device and never on an in-use filesystem or corruption is likely. 🚨 seriously, do NOT run this on something that's mounted, that's the whole warning.
  • -s <mode>, --scan <mode> β€” scan mode can be either seq or random. random reduces the chance that the disk will be able to spend time to recover data before we try to access a sector, but the seeks add noise to the latency measurement. Sequential test is the default, and random test is still experimental with regard to its usefulness. πŸ§ͺ
  • -e <size>, --size <size> β€” set the size in which the scan will be done. this must be a multiple of the sector size, which is normally 512 bytes.
  • -o <file>, --output <file> β€” set the output file that the scan will generate. this is a JSON file with the summary and details about the exceptional events found during the scan. πŸ“„
  • -r <file>, --raw-log <file> β€” set the output file for the raw log, which logs everything done and seen during the scan. this is a rather large file, but it can help get the finer details of the scan progress and the disk behavior during the scan. this is too a JSON file. πŸ—‚οΈ

🌈 SEE ALSO 🌈

badblocks(1), fsck(1)


πŸ’œ AUTHOR πŸ’œ

Baruch Even <baruch@ev-en.org>


okay that's the whole page bestie, every last flag accounted for, not one detail dropped, periodt. πŸŽ€

sign-off cuteness: this was DiskScan 0.19, dated 2013-10-25 β€” a vintage queen, still eating. πŸ’…βœ¨ go check your disks, love you, bye! πŸ¦‹