"Резиновый" образ ФС

Как создать обычный образ ФС, знают все (ну почти все):
dd if=/dev/zero of=/path/to/file count=nnnn
mkfs.ext3 /path/to/file

В общем как-то так. Проблема в том, что такой образ занимает место, равное nnnn*512 байт.
Можно-ли как-то создать динамический образ, который будет распухать по мере заполнения, а не забивать всё место, про которое ему намекнули? Как умеют делать, напр. Virtualbox и VMware.

wetch написал:

В общем как-то так. Проблема в том, что такой образ занимает место, равное nnnn*512 байт.
Можно-ли как-то создать динамический образ, который будет распухать по мере заполнения, а не забивать всё место, про которое ему намекнули? Как умеют делать, напр. Virtualbox и VMware.

[console]dd if=/dev/zero | gzip -c >/path/to/file.gz[/console]

можно забить диск нулями (/dev/zero), а затем просто скопировать образ

man cp написал:

By default, sparse SOURCE files are detected by a crude heuristic and the corresponding DEST
file is made sparse as well. That is the behavior selected by --sparse=auto. Specify
--sparse=always to create a sparse DEST file whenever the SOURCE file contains a long enough
sequence of zero bytes. Use --sparse=never to inhibit creation of sparse files.

пруф для тех кто в танке:
[console]ksu@ksu:~$ du -h .aMule/Temp/042.part
141M .aMule/Temp/042.part
ksu@ksu:~$ ll -h .aMule/Temp/042.part
-rw-rw-rw- 1 ksu users 381M 2011-02-09 16:25 .aMule/Temp/042.part
[/console]

partimage? clonezilla?

Battle Coder написал:

partimage? clonezilla?

Не вариант, т.к. эти делают бэкапы, а мне надо работать с образом в реальном времени

drBatty написал:

можно забить диск нулями (/dev/zero), а затем просто скопировать образ

Судя по всему такой образ в момент распухнет до максимального размера

drBatty написал:

[console]dd if=/dev/zero | gzip -c >/path/to/file.gz[/console]

Тут не догнал как потом с ним работать. Как создать ФС? Как подмонтировать?

wetch написал:

Не вариант, т.к. эти делают бэкапы, а мне надо работать с образом в реальном времени

wetch написал:

Проблема в том, что такой образ занимает место, равное nnnn*512 байт.

дело в том, что образ EXT4 внутри EXT4 хоть и имеет размер nnnn*512 (а скорее m*4096), но занимает намного меньше места. блоки в 4096 байт равные 0000000.... не хранятся на диске.

drBatty написал:

ksu@ksu:~$ du -h .aMule/Temp/042.part
141M .aMule/Temp/042.part
ksu@ksu:~$ ll -h .aMule/Temp/042.part
-rw-rw-rw- 1 ksu users 381M 2011-02-09 16:25 .aMule/Temp/042.part

видите? файл размером 381М занимает 141М на диске. Это свойство ФС - в отличие от NTFS не нужно включать "разряжённые" файлы, они все такие.

wetch написал:

Не вариант, т.к. эти делают бэкапы, а мне надо работать с образом в реальном времени

Оу... ну значит вам нужна ZFS. я так понял? :)

drBatty написал:

блоки в 4096 байт равные 0000000.... не хранятся на диске.

файл размером 381М занимает 141М на диске. Это свойство ФС - в отличие от NTFS не нужно включать "разряжённые" файлы, они все такие.

Я всё прекрасно понял (даже увлёкся экспериментом и упихал на 1Мб диск 123Гб файлов). Теперь объясняю что я хотел сказать:

[console]wetch@server:/tmp$ dd if=/dev/zero bs=1M count=1000 > file
1000+0 записей считано
1000+0 записей написано
скопировано 1048576000 байт (1,0 GB), 1,19619 c, 877 MB/c

wetch@server:/tmp$ cp --sparse=always file file.0

wetch@server:/tmp$ du -h file*
1001M file
0 file.0

wetch@server:/tmp$ mkfs.ext4 file

wetch@server:/tmp$ mkfs.ext4 file.0

wetch@server:/tmp$ du -h file*
1001M file
33M file.0

wetch@server:/tmp$ cp --sparse=always file.0 file.1

wetch@server:/tmp$ du -h file*
1001M file
33M file.0
580K file.1
[/console]

прикол в том, что если в каких-то блоках виртуальной фс побывали данные, то на корневой фс место под эти блоки уже выделяется, а значит стоит разок поработать с виртуальной фс, и она заполнит всё назначенное ей место на диске и придётся снова обработать с помощью $ cp --sparse=always

Меня интересует динамическое использование места на диске, так, чтобы дописал данные в виртуальную ФС, файл образа увеличился, удалил данные, образ уменьшился.

man chattr на предмет опций c & s
правда, видимо придётся ядро пересобирать. других вариантов не знаю, к сожалению.
ну ещё можно удалять файлы не rm, а shred -z.

кстати, если второй обработать образ cp, он уже не уменьшиться :(