The manual for dd
does not describe oflag
very well, but this answer from @guiverc explains it very nicely:
Write in append mode, so that even if some other process is
writing to this file, every ‘dd’ write will append to the
current contents of the file. This flag makes sense only for
output. If you combine this flag with the ‘of=FILE’ operand,
you should also specify ‘conv=notrunc’ unless you want
The conv=notruc
part is explicitly mentioned in the note for oflag
, which tells the system to not truncate an existing file. I cannot find anything of value in an Ubuntu-specific manual, but this StackOverflow answer explains the flag as such:
If the file already exists and is a regular file and the open mode allows
writing (i.e., is O_RDWR or O_WRONLY) it will be truncated to length 0. If
the file is a FIFO or terminal device file, the O_TRUNC flag is ignored.
Otherwise the effect of O_TRUNC is unspecified.
Essentially, the existing file will not be reduced to 0 bytes, but instead have the existing data left intact and new data appended to the end of the file in a contiguous fashion.
However, this should raise a question: What happens if there is a file that exists in the space that is to be consumed by the swap file as it expands?
This is where things get interesting.
Because you are telling the system to make the file contiguous, if there is another file in the way of a natural expansion of a file on a spinning disk drive, then the entire file will be moved to a location where there is enough contiguous space to support the file. If the disk is heavily fragmented and there is not enough space, a No space left on device
error will be thrown. However, on a solid state disk, this is a non-issue and the file will have the additional space applied to the existing file, even if the 0
bits are stored in separate flash modules.
Note: See Mark G. Sobell's (very old) Practical Guide to Ubuntu Linux for more on this.
So, with this said:
Q. How do the oflag and conv parameters work?
See above.
Q. Should be expected a well defined continuity of the new blocks added with zero to the current size of the swap file?
Yes. See above.