[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

a few minor bugs in the D-L Manual



>>>>> Daniel Baumann <daniel@debian.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
 > debian-live.alioth.debian.org).

	ACK, thanks.

	What about the following?

--cut: http://live.debian.net/manual/html/persistence.html--
$ dd if=/dev/zero of=live-rw bs=1024k count=1 seek=1k # for a 1G image file
# mkfs.ext2 -F live-rw
--cut: http://live.debian.net/manual/html/persistence.html--

	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
 | lost

	... 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.

[...]


Reply to: