Tag Info

Hot answers tagged

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

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


11

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


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


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.


6

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


6

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


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


5

That was very true a decade ago, when drive IO speeds were the major bottleneck. In fact, it was recommended placing your swap on a separate drive, to keep it off your primary's BUS. IO speeds have improved since then, partition placement for performance tweaks are negligible now. To add, and assuming placing swap closer would improve performance, it would ...


5

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


4

Since the data has to be decrypted to be usable, it will be available in an unencrypted state during runtime. You should treat it as though the provider can access the live running system at any time without your knowledge. This includes data at rest on disk, data contained in memory (such as decryption keys) and even any keystrokes you send (i.e., assume ...


4

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


4

Use umount. You ran umount -l, which specifically tells umount to leave the filesystem mounted until all processes are done with it. You really shouldn't need umount -l most of the time; the only purpose it serves is freeing up the mount point so you can mount something new there while the currently mounted partition is still in use. Now that you've already ...


3

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.


3

With the update (lshw … output) there is the answer now: product: xD/SD/M.S. That's your laptop's cardreader. Also, capabilities: removable. UPDATE: As for the mentioned /sys/block/sdb/queue/rotational value being 1, this parameter actually influences the I/O scheduling algorithm in Linux. Probably, it should have been named something like 'minimize-seek' ...


3

Those two sections are for different things. The first is for unplugging. The second is for plugging. For unplugging, the OS will sync the data during the unmount operation. Thus, if the disk is unmounted (assuming you in fact do have full hardware support) you can power off the disk then unplug it without risk of data loss or corruption. For plugging, ...


3

The extended and logical partitions make sense only with msdos partition table. It's only purpose is to allow you to have more than 4 partitions. With GPT, there are only 'primary' partitions and their number is usually limited to 128 (however, in theory there is no upper limit implied by the disklabel format). Note that on GPT none of the partitions could ...


3

50GB for rootfs is huge, it is better to check why the filesystem is filled than to blindly extend it. If you just extend the root filesystem, chances are that it will fill up again in a short time. I expect /var, /var/log or /tmp to be filled. In my experience this is usually caused by a large collection of relatively small(ish) files and therefore it is ...


3

Q1. Try something like sudo du -a -m -x | sort -k1n -r | head -n40. The -a flag to du says to be recursive. The -m flag displays sizes in MB. The -x stays on a single filesystem. This will list both files and directories, and only the 40 largest (because of the -n40 option to head). Some du implementations have a -t SIZE option to only display entries whose ...


3

That is possible. It requires another Linux to boot (CD/DVD is OK) some spare space outside the PV (100M would be good) a certain amount of fearlessness... Then you copy a block from the encrypted volume to the area outside the PV and (after success) to the unencrypted base device. After that you increase a counter in the safe area so that you can ...


2

There is no way to be safe against a malicious hosting provider, they can access your data no matter how you try to avoid it. A few simple examples: Encrypted SSH traffic can be discovered by taking the host key from the host filesystem and putting another SSH server as a man-in-the-middle that decrypts the traffic and negotiates with your SSH server. ...


2

It's very likely your system drive is sda given the big number of partitions. To make sure of that, you could use the output of mount, df -h or lsblk and look for where / is located. Avoid that drive. Other than that, both sdb and sdc are valid candidates. Mounting them and looking at the contents is the safest way. What could be quicker is as simple as ...


2

On most non-embedded Linux installations, and many embedded installations, /dev is on a RAM-backed filesystem, not on the root partition. Most current installations have /dev as a tmpfs filesystem, with the udev daemon creating entries when notified by the kernel that some hardware is available. Recent kernel offer the possibility of having /dev mounted as ...


2

You can do that. You need to be a bit careful, but this is not dangerous¹ if you are very careful not to mistype anything and it doesn't leave any gotchas in the setup. I highly recommend not doing any of the manipulations on a live system. It's possible in some cases but requires extra care. Boot from a liveCD/liveUSB such as Parted or SystemRescueCD. ...


2

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


1

That's what's supposed to happen. There are two colloquial uses of the term "disk" or "drive" in play here: the first one refers to a physical device such as a usb stick. The second refers to a filesystem partition, of which there may be several on one physical device. Device nodes like /dev/sda refer to the first sense (physical devices); device nodes ...


1

I fear you destroyed most of the system by now, your only solution is to reinstall. But by the amount of problems you have, I'd run a memory test (memtest, probably an option on your installation media, leave it running a few hours), and run some disk diagnostics (the disk might be shot, that could explain some of the symptoms like failing mount and fsck ...


1

There is a little part of a script I wrote to create and install live usb key, (dual boot ubuntu - debian): The very first part USBKEYS=... is the answer to this question #!/bin/bash export USBKEYS=($( grep -Hv ^0$ /sys/block/*/removable | sed s/removable:.*$/device\\/uevent/ | xargs grep -H ^DRIVER=sd | sed s/device.uevent.*$/size/ | ...


1

ext4 does not support online shrinking. You can not shrink an ext4 volume without unmounting it (with or without LVM). If the problem is that this is your rootfs, you may be able to do the shrink from initramfs—depends on if you have console access (e.g., IP KVM). If instead you wish to grow it, that's doable, provided you have free space after the ...


1

Root VG? You mean your root LV? If so, that's impossible to shrink while root is online, (you could fall back to ramfs if you have physical access). The only way to do it, is boot from an external media (or partition), and resize the root partition with resize2fs with lvresize



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