Tag Info

New answers tagged

2

rootfs mounted on / is an in-memory filesystem which typically only contains the tools needed to mount the “real” root filesystem and is emptied after this is done. The initial content of the rootfs are loaded from an initramfs image stored inside or next to the kernel binary and loaded by the bootloader. The root filesystem on flash is ubi0:root. This is a ...


9

I think you can use UDEV to do what you want. Creating a rules file such as/etc/udev/rules.d/99-thumbdrives.rules you'd simply add a rule that will allow either a Unix group or user access to arbitrary USB thumb drives. KERNEL=="sd*", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", OWNER="<user>", GROUP="<group>", MODE="0660" Would create the device ...


-1

Now that I look again, I realized you said this was a usb key ( flash drive ) not a hard drive. Flash memory can only be erased in large blocks, and individual sectors can not be written without erasing them ( and the whole block they are in ) first. Since software expects to be able to write wherever it wants on the disk at any time, the disk has ...


-1

This happens due to the optimization of writing Sparse files in filesystem. When you do dd if=/dev/zero to raw device, the zero blocks are actually written to disk. However when you write them to a file, the filesystem ignores writing the data and saves just the metadata. This results in very few blocks being written to disk. The file can be seen as a big ...


0

Try using hdparm instead to benchmark a drives performance with and without using any caching: $ sudo hdparm -tT /dev/sda1 /dev/sda1: Timing cached reads: 6314 MB in 2.00 seconds = 3157.61 MB/sec Timing buffered disk reads: 244 MB in 3.04 seconds = 80.26 MB/sec


0

Your measurement results can be explained with the kernel architecture. Using filesystem access will unlease the full potential of the kernel with all buffers and optimizations that it can do. Especially the buffers will speed up your benchmark (b/c the kernel is 100% a_A_syncronous). dd on a device file does not use any/much of this.


1

Updating the running system so that the new root image will be used on the next reboot is a little more complicated than just doing a straight copy across the network. Assuming that the root image is on /dev/mmcblk0p5 (as indicated by the output of parted -l and the comments above), the OP should should be able to copy the root partition from the image to ...


0

@maxschlepzig asks for a online liner. Here is one in perl. It takes 2 argument: From byte and length. The input file must be given by '<' and the output will be on stdout: perl -e 'sysseek(STDIN,shift,0) || die; $left = shift; while($read = sysread(STDIN,$buf, ($left > 32768 ? 32768 : $left))){ $left -= $read; syswrite(STDOUT,$buf); ...


1

Assuming you have an SSH server on your Raspberry and the SD card on the Raspberry shows up on /dev/sda, you would do something like this: dd if=SDcardimage.img | ssh -o MACs=hmac-ripemd160 -l raspberry-pi-user <your Raspberry's IP address> 'dd of=/dev/sda' I explain: dd outputs to standard output when no of output file is specified, and reads ...


3

You can pipe through SSH: dd if=something | ssh host dd of=something But you should have a better reason for using dd than a simple file copy operation where you are better off with scp, rsync, and the like.


3

bs=1 tells dd to read and write one byte at a time. There is an overhead for each read and write call, which makes this slow. Use a larger block size for decent performance. When you copy a whole file, at least under Linux, I've found that cp and cat are faster than dd, even if you specify a large block size. To copy only part of a file, you can pipe tail ...


4

Summary: dd is a cranky tool which is hard to use correctly. Don't use it, despite the numerous tutorials that tell you so. dd has a “unix street cred” vibe attached to it — but if you truly understand what you're doing, you'll know that you shouldn't be touching it with a 10-foot pole. dd makes a single call to the read system call per block (defined by ...


2

The warning occurs when dd could not get enough data to fill a block in a single read. This happens with erratic or slow data sources, or sources that write data in smaller units than your requested blocksize. There is no problem with data integrity, but the problem is that dd counts a partial read still as a read block. If you are not using the count ...


1

With dd: dd if=1tb skip=12345678901 count=$((19876543212-12345678901)) bs=1M iflags=skip_bytes,count_bytes Alternatively with losetup: losetup --find --show --offset 12345678901 --sizelimit $((19876543212-12345678901)) And then dd, cat, ... the loop device.


9

This is slow because of the small block size. Using a recent GNU dd, the simplest way is to use the skip_bytes and count_bytes options: in_file=1tb start=12345678901 end=19876543212 block_size=4096 copy_size=$(( $end - $start )) dd if="$in_file" iflag=skip_bytes,count_bytes,fullblock bs="$block_size" \ skip="$start" count="$copy_size" Update ...



Top 50 recent answers are included