Tag Info

Hot answers tagged

59

For disk I/O trending there are a few options. My personal favorite in the sar command from sysstat. By default, it gives output like this: 09:25:01 AM CPU %user %nice %system %iowait %steal %idle 09:35:01 AM all 0.11 0.00 0.01 0.00 0.00 99.88 09:45:01 AM all 0.12 0.00 0.01 0.00 ...


32

With udev, You can use ls -l /dev/disk/by-label to show the symlinks by label to at least some partition device nodes. Not sure what the logic of inclusion is, possibly the existence of a label.


31

Have a look at iotop. Or iodump, if that's more down your way of thinking. Note: This requires at least kernel 2.6.20 to work.


29

Naturally, you need to unmount any filesystems on the disk, and it'd be a good idea to deactivate any LVM groups (vgchange -an), and generally make sure nothing is using the disk for anything. Once you've done that, it should be safe to unplug. If you want to be extra cautious, do echo 1 > /sys/block/(whatever)/device/delete first. That'll unregister ...


28

Why don't you just use lsblk? For instance: # sudo lsblk -o name,mountpoint,label,size,uuid NAME MOUNTPOINT LABEL SIZE UUID sda 1.4T ├─sda1 /boot boot 953M f557b9f0-edb5-42bb-94d8-27bc03c3c2c7 ├─sda2 ...


23

I like dstat. It can show totals and statistics per disk and even md-devices (RAID), also can use colors for better overview: $ dstat -tdD total,sda,sdb,sdc,md1 60 ----system---- -dsk/total----dsk/sda-----dsk/sdb-----dsk/sdc-----dsk/md1-- time | read writ: read writ: read writ: read writ: read writ 08-11 22:08:17|3549k 277k: 144k 28k: 851k ...


16

There is a blkid command which may be what you are looking for. Results are similar to the following: $ sudo blkid /dev/mapper/vg_rootdisk-lv_var /dev/mapper/vg_rootdisk-lv_var: LABEL="LV_VAR" UUID="08520908-03cd-4e42-a4e4-0f5a771be16c" TYPE="ext4" One other option is to use the udevadm command, which likely will give you far more than you need: $ sudo ...


15

Assuming you're on Linux. Try: sudo /lib/udev/scsi_id --page=0x80 --whitelisted --device=/dev/sdc or: cat /sys/block/sdc/device/{vendor,model} You can also get information (including labels) from the filesystems on the different partitions with sudo blkid /dev/sdc1 The pathid will help to determine the type of device: readlink -f ...


13

As a general rule, physical access to the machine is all that's ever needed to compromise it. You are, after all, trusting that what the machine tells you is true; a person with physical access can void that trust. Consider that an attacker with physical access can theoretically do anything (including installation of hardware/firmware rootkits, etc). If the ...


10

Just from files on your computer (assuming a recent kernel) you can ask /sys/block/sda/stat or /proc/diskstats. It will need some translating, however. But it's nice for a quick and dirty check.


10

I know dd is supposed to be a power user tool but still, it doesn't make sense to me that you can basically screw your whole computer by hitting the wrong key. Consider the kinds of power tools used in civil construction and what you can screw up by doing one little thing wrong. Could those things be made more preventable? Probably, but the counter ...


9

If you are using /dev/sda1 as your current system root, you will be unable to unmount it, and doing so would prevent you from running parted from it anyway. resize2fs is able to enlarge ext3/4 filesystems while mounted on newer kernels, but not shrink them. Your best bet is probably to use the gparted live CD or gparted included with System Rescue CD. ...


9

On recent version of Linux, there are /dev/disk/by-{id,label,path,uuid} directories that contain automagic symlinks to the various /dev/sdX and /dev/sdXN entries (I believe all of these are setup by udev). These provide more stable and informative names for your disks and partitions. I find /dev/disk/by-label/ the most useful (especially if you label your ...


9

Your 8GB stick has approximately 7.5 GiB and even with some file system overhead should be able to store the 5.4GiB file. You use tune2fs to check the file sytem status and properties: tune2fs -l /dev/<device> By default 5% of the space is reserved for the root user. Your output lists 97894 blocks, which corresponds to approximately 385MiB and ...


8

Another option is to use: sudo iotop -aoP -a Will show accumulated output -o Will only output -P Will only show processes instead of threads This program will tell you how much a process has written to disk and read from disk since iotop was started.


8

Look at this page http://linuxpoison.blogspot.com.au/2009/02/how-to-measure-and-read-disk-activity.html # cat /sys/block/sda/stat 11836508 1974427 276764974 242202738 13703385 18793696 597760590 2010426698 135 76333414 2253542452 Field 3 -- # of sectors read Field 7 -- # of sectors written


8

The symlinks under /dev/disk/by-uuid/ are created by udev rules based on filesystems UUIDs. If you look at /usr/lib/udev/rules.d/60-persistent-storage.rules you will find entries like: ...... ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}" To reference a disk you could use the disk serial number and the ENV{ID_SERIAL_SHORT} key. ...


7

Using iotop. Iotop is a Python program with a top like UI used to show of behalf of which process is the I/O going on. It requires Python ≥ 2.5 (or Python ≥ 2.4 with the ctypes module) and a Linux kernel ≥ 2.6.20 with the TASK_DELAY_ACCT CONFIG_TASKSTATS, TASK_IO_ACCOUNTING and CONFIG_VM_EVENT_COUNTERS options on.


7

Unless you are talking about a solid-state drive, a high number of disk writes are not going to be the dominant factor in drive longevity. If you really want to avoid disk writes at all, look into tmpfs,


7

Not sure if you're looking for tools that show this type of information in a real-time type of way or over a period of time, but here are 2 tools that show the real-time aspects of the disk being accessed. nmon You invoke it like so, nmon. Then once it's open you hit the j (Filesystems) followed by a d (Disk I/O Graphs D=Stats). See the built-in help (h) ...


7

The shred command can zero out a file. To do what you want, I think something like this should work find /var/cache/pacman/pkg -type f -exec shred -n 0 -z {} \; \ && rm -rf /var/cache/pacman/pkg/*


6

udev knows your system. so you can get info through udevadm , under /sys/ like this (run as root, or with sudo depending on your distro) udevadm info -a -p /sys/block/sdb udevadm info -a -p /sys/block/sdc reading through the output you'll come across some meaningful results, such as ATTRS{vendor} ATTRS{model} you should be able to get some info about ...


6

The simple answer to the question in the title is "Yes". But what you really want to do is the next step, which is getting the existing data mirrored. It's possible to convert the existing disk, but it's risky, as mentioned, due the the metadata location. Much better to create an empty (broken) mirror with the new disk and copy the exiting data onto it. ...


6

The first idea I found is the vmstat -d command. It tells you the number of sectors written since booting. fdisk -l will tell you the sector size. By multiplying the two you can get the number of bytes touched. It seems my computer does roughly 1 gigabytes worth of writing in two hours. By doing a quick calculation a 128G SSD with 3000 write cycles would ...


6

I wrote one-liner based on Tobi Hahn answer. For example, you want to know what device stands for ata3: ata=3; ls -l /sys/block/sd* | grep $(grep $ata /sys/class/scsi_host/host*/unique_id | awk -F'/' '{print $5}') It will produce something like this lrwxrwxrwx 1 root root 0 Jan 15 15:30 /sys/block/sde -> ...


6

It's reasonable to ask why the dd command doesn't first check whether its target contains a mounted filesystem, and then prompt for confirmation or require a special flag. One simple answer is that it would break any scripts that expect to be able to use dd in this way, and that aren't designed to handle interactive input. For instance, it can be reasonable ...


6

If you are using systemd then use udisksctl utility with power-off option: power-off Arranges for the drive to be safely removed and powered off. On the OS side this includes ensuring that no process is using the drive, then requesting that in-flight buffers and caches are committed to stable storage. I would recommend first to ...


6

So assuming you are using mdadm you can do exactly what you suggest The only caveat is that the raid monitoring utility will generally only handle one disk at a time and normally when you have marked one as failed. Further you just need to ensure that it has completed copying the data before removing the old disks from the raid array otherwise you'll end up ...


5

The term for that is "dirty" data (data that has been changed, but not yet flushed to permanent storage). On Linux you can find this from /proc/meminfo under Dirty: $ cat /proc/meminfo | grep Dirty Dirty: 0 kB



Only top voted, non community-wiki answers of a minimum length are eligible