Tag Info

New answers tagged

1

Loop devices have some pitfalls. Many operations are not instant, for example, when you losetup -d the loop device will be kept alive until it is no longer in use. Devices can be in use even if you're not aware of it, due to background processes scanning devices for uuids and other things. Maybe you should leave the choice of loop device to losetup by using ...


0

I started using dcfldd(1), which shows dd operations in a better way.


2

No, you can't use dd and have any semblance of safety for your data. If you're running Oracle Solaris, then you can use the 'zpool split' command. Please see https://docs.oracle.com/cd/E36784_01/html/E36835/gjooc.html for details


1

A reliable solution requires that you ensure that nothing writes to an area that might not have been read and the only real way to achieve that is to perform the copy in a reverse direction. The ddrescue tool can work in a reverse direction but it refuses to run with the input and output being the same. However it's possible to trick it by duplicating the ...


0

You are reading 4096 blocks, and then writing those 4096 blocks to the next 4096 blocks of the disk, thus overwriting the second 4096 blocks before they can be read. You need to read 8129 blocks to get those second 4096 before starting any writing, and then you need to only write 4096 blocks before reading the next 4096. You didn't mention what kind of ...


2

Without a buffer, you could go backwards, one block at a time. for i in $(seq 100 -1 0) do dd if=/dev/thing of=/dev/thing \ bs=1M skip=$i seek=$(($i+2)) count=1 done Please note that this example is dangerous due to lack of error checking. It's also slow due to the amount of dd calls. If you have memory to spare, you could use a larger ...


1

RAID10 does not accelerate any form of O_*SYNC, at least not for small files. You're writing 512b at a time, and after each write forcing it out to disk (plus the metadata required to read it back, e.g., file size). That requires RAID10 writes to at least 2 disks, probably 4 (i.e., all your disks). And all those writes need to be completed before it can ...


-1

You're not doing "100b" (byte? blocks? what was your intention?) chunks, you're doing 512 byte chunks. That is always slow because the RAID is using 512k chunks. That means that for every 512 bytes the RAID system has to read a 512k chunk, update 512 bytes in that chunk, compute its parity, and write the data + parity out to disk. It has to do the update, ...


0

Your dd command gives me 73.7 kB/s - on a SSD. So yes I guess it's normal. Or rather, dd just isn't a good benchmark. RAID certainly does not do any speedups for small files. Access times still remain the same, and for a small file that's what will take most of the effort for HDDs, getting the read head to the physical address of the file in the first place ...


3

Yes, it is perfectly possible to mount partition images made with dd. You should add a -o loop (i.e., use a loopback device) to the mount command. The final command should look like: mount -oloop -t vfat ~/part.img /mnt Of course, you should have dd'ed from a valid and previously formatted vfat filesystem in the original partition.


1

I would just use something simple like delete the crap you don't need, then use gparted to shrink the hard drive partition and then copy it over.


0

No, don't do that. As you figured, you are likely to lose up to 25% of the data on the drive doing that, and also have a hard time recovering what is left. As long as you are able to mount the disk and copy the files, you should do that rather than try to use dd. Even if you can't mount the drive, your next tactic is to use dump ( assuming you are using ...


1

The smaller disk may be enough storage if either there is enough free space on the bigger disk or the used space can be compressed below the size of the smaller disk. Usually I would suggest to overwrite all the empty space with zeroes before making a compressed sector copy but this is not a good idea when a drive is failing. I suggest to make a file ...


0

The wchar line (written characters) in /proc/$pid/io can give you precise information about the dd process. As long as it changes, your dd is still working! Here is a neat little php script, which you can save and then execute with php filename.php during the dd to display the written bytes. The nice benefit of watching /proc/$pid/io over kill -USR1 $(pidof ...



Top 50 recent answers are included