Tag Info

Hot answers tagged

6

You will first need to reconstruct the partition table the way it was. This will not affect the contents of any partition, just the system's idea of where each partition begins and ends. It sounds like you might have already done this because you seem to have a partition that exists that is "unknown", but exactly the same size as the partition was before. ...


5

I've not used this tunable before but you probably want to adjust the eh_timeout (error handling timeout) for the drive in question: [root@localhost device]# cat /sys/block/sda/device/eh_timeout 10 [root@localhost device]# The above shows sda set to 10 seconds. From Red Hat Knowledgebase: In certain storage configurations (for example, configurations ...


5

If the filesystem takes over the whole disk, OS X currently uses a name like /dev/disk5. If the disk is partitioned, it adds an s# suffix, like /dev/disk5s2 for the second partition. (s is short for "slice," a BSDism functionally equivalent to a partition.) Disks are numbered sequentially in discovery order by the OS, on boot, so you may have to experiment ...


3

It depends. There is no general answer to this question. In the absence of caching, writing a disk file is usually measurably slower than reading. This has little to do with the operating system and everything to do with the hardware: both hard disks and solid state media read faster than they write. A secondary factor is related to filesystem structure: ...


2

Monitor /sys/block/<dev>/stat for the devices you're interested in and compare the 10th parameter (io_ticks). eg, ticks = io_ticks - prev_ticks / seconds_deltatime / 10 This is the percentage of available time that the disk has spent waiting for disk io. Close to 100% would be worth checking of course, or else get really clever and compare it to the ...


2

You need to use the write sync flags to test performance, to ensure you are actually writing on disk and not on cache. Use conv=fdatasync to force a sync of buffers after writing has ended. See here for details. time dd .... conv=fdatasync for read test, discard caches before testing: flush echo 3 | sudo tee /proc/sys/vm/drop_caches time dd ....


2

Modern disks these days usually contain a number of spare sectors that are automatically put into service should a problem in one sector is found. If you run out of these spare sectors, then you are looking at a disk that is in pretty bad shape. Instead of attempting to zero out the bad blocks and continuing, I'd get a new disk and install it. It's far ...


1

When grepping a disk - unless you're actually looking for non-printable information - you might like to do: tr -c '[:print:]\n' '\n\n' </dev/disk | grep -b 'regex' All binary data is converted to newlines and grep can simply ignore it except to increment the offset it reports on by one.


1

Writing should be faster. The free block list is kept in memory, so finding the next free block will be very fast. Unless you're writing in synchronous mode, when you try to write something it will simply copy the data into a kernel buffer and queue the write; it doesn't have to wait for the I/O to complete. On the other hand, a read has to wait for the ...


1

I'm very doubtful that you can get meaningful benchmarks from dd. dd just shows you how large sequential reads or large sequential asynchronous writes perform between various devices. As long as your workload consists mainly of copying large files between these filesystems you're alright. I doubt that's your workload, though. Your best bet is to profile ...


1

What was the command you used? dd does very different things related to percormance depending on the options. But from what you write, I think you were reading small blocks, which will get read from the disk as you ask for them, roughly. And you where writing small blocks, which will be written to the disk when the kernel feels it has time to do it - ...


1

You could, but if any file crosses the split boundary, you won't be able to recover it. Of course, you could go for overlapping splits to avoid that problem (overlap size being at least the maximum file size you're expecting to recover). However, it's questionable at best whether you would actually see the desired speed increase. Suppose you want to go for ...


1

In the following, LABEL can be anything you want, /dev/sdb1 is the partition you create and choose to use on your new HDD and /var/www/myfiles is where your files are currently located. Alter these to suint your scenario. Partition the new HDD. You can have one partition that takes up the whole disk, or make a smaller partition which leaves you space on ...


1

This is related to the file system you intend to use. Some of them, such as EXT4 or ReiserFS, allow to mark bad sectors: see the -c option of e2fsck or the -B option of reiserfsck. I think this works on other file systems as well. If you choose this way you should partition and format the hard disk with bad blocks control enabled, and proceed with the ...


1

As someone said, the GParted doesn't copy the boot sector. To solve this problem, you need to boot with a LiveCD and then run the following commands: sudo mount /dev/sda3 /mnt sudo grub-install --root-directory=/mnt /dev/sda Considering that sda3 is your new partition



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