Tag Info

Hot answers tagged

93

Don't go straight to du /. Use df to find the partition that's hurting you, and then try du commands. One I like to try is du -h <dir> | grep '[0-9\.]\+G' because it prints sizes in "human readable form". Unless you've got really small partitions, grepping for directories in the gigabytes is a pretty good filter for what you want. This will ...


46

du can be depth-restricted: du -d 5 Will only recurse to depth 5. /EDIT: This counts only for the display; the tool will still determine the total size of the whole directory tree but this is still much faster than running a full du.


39

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 ...


22

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 ...


22

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.


14

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

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 ...


12

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 ...


11

Finding the biggest files on the filesystem is always going to take a long time. By definition you have to traverse the whole filesystem looking for big files. The only solution is probably to run a cron job on all your systems to have the file ready ahead of time. One other thing, the x option of du is useful to keep du from following mount points into ...


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

I always use du -sm * | sort -n, which gives you a sorted list of how much the subdirectories of the current working directory use up, in mebibytes. You can also try Konqueror, which has a "size view" mode, which is similar to what WinDirStat does on Windows: it gives you a viual representation of which files/directories use up most of your space. Update: ...


9

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 ...


8

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 ...


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


7

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.


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/*


7

For the commandline I think the du/sort method is the best. If you're not on a server you should take a look at Baobab - Disk usage analyzer. This program also takes some time to run, but you can easily find the sub directory deep, deep down where all the old Linux ISOs are.


7

I use this for the top 25 worst offenders below the current directory # -S to not include subdir size, sorted and limited to top 25 du -S . | sort -nr | head -25


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 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 -> ...


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


5

Yes, it is true. The platters in a disk rotate at a fixed speed (7200 RPM in the common case). As such when the head is over the outer portion of the platter more surface area passes under the head per rotation than on the inside track. Thus more IO per rotation is possible. (The 'beginning' of the drive is the outside tracks of the platters) Now whether ...



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