I am trying to install chrooted debian (arm64) on my android phone(snapdragon650 & 3GB RAM). I found many tutorials for it. Almost all the guides mentioned this cmd for creating img for chrooted debian.

 dd if=/dev/zero of=jessie-arm64.img bs=1M count=0 seek=5120

Here bs=1M . I don't know much about dd. But I think bs parameter is gonna affect ::

  1. read/write speed on img
  2. Space allocation to files & their file size

I am going to use chrooted environment for compiling source code for arm64 and running a bit heavy gui programs (in openbox or xfce ). I want that value for bs which would be optimum for both read/write speed and space utilisation.

  • This dd command zeros the image. It seems likely that you will only be doing this once. Speed should not matter. – Stephen Rauch Jan 14 '17 at 8:03
  • What about the file size like a file having actual file size 300KB but taking space 1MB on img ? – jonny789 Jan 14 '17 at 8:12
  • @Gilles not a duplicate in this case, as the bs is only used by the human and not the hardware in this case. – icarus Jan 15 '17 at 22:38

The count=0 parameter is very significant here, this command is just being used to create a file of a particular size, nothing is actually being copied.

Therefore there is no optimal value for bs from the hardware point of view

The created file will have size bs * seek. The bs of 1 megabyte just makes it easy to see that you are creating a file with size 5120 megabytes.

At a system call level, this is just going to do an open, an lseek and a close call. dd will do the bs * seek calculation and give it to the lseek system call. So bs if=/dev/zero seek=5368709120 bs=1 of=jesse-arm64.img will produce exactly the same system calls.


First, some details about the command

dd if=/dev/zero of=jessie-arm64.img bs=1M count=0 seek=5120

From the man page of dd :

  • if=FILE read from FILE instead of stdin

  • of=FILE write to FILE instead of stdout

  • bs=BYTES read and write up to BYTES bytes at a time

  • count=N copy only N input blocks

  • seek=N skip N obs-sized blocks at start of output

We have count=0, so 0 input block will be copied but we have seek=5120 so 5120 blocks of size obs will be skipped. obsis the output block size, in our case it's not specified so obs=bs=1M.

If you want you can even remove the if=/dev/zero and obtain the same result.

dd of=jessie-arm64.img bs=1M count=0 seek=5120

Now the question of optimum value for bs, we observe in the source code of dd that even if count=0 blocks are copied, we have seek=5120 (seek_recordsin the source code) and the bs (obs, output_blocksizeint the source code) value is used.

  if (seek_records != 0 || seek_bytes != 0)
      size_t bytes = seek_bytes;
      uintmax_t write_records = skip (STDOUT_FILENO, output_file,
                                      seek_records, output_blocksize, &bytes);
      if (write_records != 0 || bytes != 0)
          memset (obuf, 0, write_records ? output_blocksize : bytes);
              size_t size = write_records ? output_blocksize : bytes;
              if (iwrite (STDOUT_FILENO, obuf, size) != size)
                  error (0, errno, _("writing to %s"), quoteaf (output_file));
                  quit (EXIT_FAILURE);
              if (write_records != 0)
                bytes = 0;
          while (write_records || bytes);

The optimum value of bsis dependant of your hardware, here is an article explaining how to measure it. I will not go in detailed explanations here, because this answer is becoming too long.


1) You can observe your image in hexadecimal format with :

cat jessie-arm64.img | xxd

2) This is valid for the dd command from the GNU coreutils. If you are using a BSD-style dd command such as in macOS, you have to use bs=1m instead of bs=1M.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.