Hi, i wrote: > > I let xorriso-dd-target use > > bs=1M oflag=dsync
Max Nikulin wrote: > May too small bs value cause write multiplication if internal flash erasure > block size is much larger? [...] My concern is wearing, Is there evidence that sync size a smaller than such an internal size is harmful ? Writing small chunks would also happen with any scattered writing with smaller chunks, which would happen when medium sized files get written here and there in the (FAT) filesystem. Firmware could try to accumulate data in finer granulated memory as long as the data would go to the same physical chunk, and only later write to the coarsly granulated memory. Sequential writing by dd would well fit into such a caching strategy. Jeff wrote: > I've run into this situation (more than once)... `dd` fails to write a > bootable image with a block size of 1M. But using a block size of 512 > results in a bootable image. It used to happen regularly on arm dev > boards, like BeagleBoards and CubieTrucks and Wandboards. I would be interested in more details (error messages ? no booting ?). > I don't recall it happening lately. If it happens again, please report. If ever, bs=512 would invite for more extra block erasures than bs=1M. Max Nikulin wrote: > I have no idea if firmware may perform > partial overwrites without apparent impact on speed. Is there evidence ? I know from own experiments that very small sizes like bs=512 cause slow copying with and without oflag=dsync. Also very large sizes yielded less throughput than bs=1M. (My sample set of USB sticks used is small.) > Are you against "sync" command because it syncs all drives, I understand dd oflag=sync only applies to the target file or device and that the difference to oflag=dsync is about metadata of the target file like its timestamps. But xorriso-dd-target runs sync(1) in the end. Just to be sure. (Sorry for any other data which get onto storage device early.) > From my point of view, simple cp suggested by the install guide > is quite reasonable in comparison to dd. cp is not suitable for erasing the last block of the USB stick where the header of the backup GPT may reside, if the stick was GPT partitioned. cp does not display pacifier messages and may end substantially earlier than the write process from kernel to USB stick. > Another my question is concerning reading of media and -x argument of > isosize. Is it really necessary? I can not figure out what corner cases > are not covered by "head -c BYTES /dev/sdc". If you put emphasis on avoiding dd, then this would be an alternative. Have a nice day :) Thomas
