a few minor bugs in the D-L Manual
>>>>> Daniel Baumann <firstname.lastname@example.org> writes:
>> Wiki reads:
> general note: the wiki is pretty much outdated in *many* cases and
> the primary location for any information is the manual (linked on
What about the following?
$ dd if=/dev/zero of=live-rw bs=1024k count=1 seek=1k # for a 1G image file
# mkfs.ext2 -F live-rw
This is a bit bogus: if one's going to create a sparse file, why
bother writing even a single zero-filled 1 MiB block (not to
mention that the file will be of 1025 MiB size then)?
$ ls -gGl live-rw
-rw-r--r-- 1 1074790400 ... live-rw
Rather, it should look like:
$ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1G image file
$ ls -gGl live-rw
-rw-r--r-- 1 1073741824 ... live-rw
Also, there's no point in going superuser in order to use `mkfs'
(on a regular file that one's own); consider:
$ /sbin/mkfs -t ext2 -F live-rw
Block size=4096 (log=2)
Fragment size=4096 (log=2)
131072 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
One more rough paragraph is:
| The content of a snapshot could reside on a partition or an image
| file (like the above mentioned types) labeled live-sn, but it
| defaults as a simple cpio archive named live-sn.cpio.gz.
... it defaults to... ?
| As above at boot time, the block devices connected to the system are
| traversed to see it a suche named partition or file
... if a partition or a file named like that... ?
| could be found. A power interruption during runtime could mean data
... could lead to the data loss... ?
| hence a tool invoked live-snapshot --refresh could be called to sync
| important changes. This type of persistence since no not write
..., since it doesn't write... ?
| continuosly to the persistent media is the most flash-based device
| friendly and the fastest of all the persistence systems.
> having that said, some pages that were already incorporated into the
> manual were for unknown reason not deleted from the wiki.