0

I have a 4 disk NAS configured as a raid 5 but unfortunately the raid recently became unrecognisable, but the NAS boots fine otherwise. I'm in the process of cloning disks so raid recovery can be attempted. I'm using a bootable Ubuntu live USB on standalone desktop to complete operation. While cloning one of the drives I get an error message about disk space.

Command used

dd if/dev/sda of/dev/sdb status=progress bs=16K conv=sync,noerror

Error Message

DD: error writing '/dev/sdb': No space left on device.

Both devices are 2TB HDD's.

I can provide a screenshot of terminal if required.

Is this normal with DD? Is it something to do with writing 0's to all unreadable/unallocated space. Or incorrect partition on sda? would using a larger capacity sdb assist?

Help appreciated.

Improve this question
3
  • 1
    Please do not post screenshots of a commands output, instead copy and paste the output as text into appropriate code tags.
    – mashuptwice
    Commented Mar 17, 2022 at 2:27
  • 1
    Of you arw wroting all zeros (not sure why you would do that here) its entirely probable tha that you would get that error when the hard drive is fully overwritten. /dev/zero is infinitely large.
    – davidgo
    Commented Mar 17, 2022 at 3:49
  • Probably because the (same) size of both drives is not a multiple of 16KiB (the bs= you used). I don't think there's anything to worry about, but you can hash or cmp the drives if you are paranoid.
    – Tom Yan
    Commented Mar 17, 2022 at 6:13

1 Answer 1

Reset to default
1

It's a result of bs=16k and conv=sync when the capacity of your drive is not a multiple of 16KiB (16384 bytes).

From dd(1):

...

Each CONV symbol may be:

...

sync pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs

...

Therefore in your case, dd is expected to pad the data from the if= drive with 8KiB (16384 - 2000398934016 % 16384 = 8192) of NULs (zeroes) at the very end, but there are no extra sectors / logical blocks on the of= drive available for those extra bytes, as the two drives have exactly the same capacity, which results in the error.

If of= were a regular file, you'd see that the output is 8KiB larger than the capacity of the if= drive (assuming that the file can fit into the drive that contains it, of course).

Improve this answer
2
  • Thanks very much for taking the time to explain. Appreciated. So you're saying that in my case the if= total bytes (2000398934016) has to be divisible by 16384 (if I choose to set bs=16K) which it isn't - and as such, by using the Conv=sync I've forced it to try and write more data (0's) than the capacity of of= (same as if= in this case). It could potentially try and write up to 16383 bytes extra in the last block which, although throwing an error, should not impact negatively on subsequent raid reconstruction attempts. Am I in the ball park?
    – shreckuare
    Commented Mar 17, 2022 at 12:12
  • Yeah pretty much.
    – Tom Yan
    Commented Mar 17, 2022 at 12:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .