Вопрос о btrfs, cow, nodatacow

Как известно в btrfs использует COW, копирование при записи. Как я понел при изменении файла мы изменяем не файл а новый блок в фс. Благодаря этой фитче мы можем получать оригинальные файлы которые были изменены 2 года назад?

Мне такой функционал не нужен, мне нужна обычная btrfs, со сжатием.

nodatacow отключает не только cow, но и ген хеша, + выборочное сжатие, работает лишь force compress. Ну и вроде стабильность падает так как блоками фс и сама пользуется при потери питания например.
Вопрос: COW вечно создает такие блоки? Можно даже и не знать что у тебя множество разных модификаций одного и того же файла?
Вы совершенно не так поняли, как работает COW. Рекомендую читать документацию до полного просветления.
И COW никому никаких проблем не создает, а улучшает стабильность и отзывчивость файловой системы.
Хорошо, посоветуйте ссылку где подробно описан COW на btrfs. Как известно в btrfs слижком много мета данных(включая эти модифекации модифекаций), и свободное место заканчивается на глазах после долгой жизни btrfs.
А может я не прав, я вспомнил одну вещь. Кроме snapper я случайно ставил хук на пакман который автоматом после каждого обновления системы делал снимок. Поэтому получались копии, не думаете?
Ulin
в btrfs слижком много мета данных(включая эти модифекации модифекаций)
Это много?
$ btrfs filesystem df /
Data, single: total=22.00GiB, used=16.41GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=338.72MiB
GlobalReserve, single: total=29.86MiB, used=0.00B
На данный момент столько снимков:
# btrfs subvolume list -at --sort=path /
ID	gen	top level	path
--	---	---------	----
258	5046	5		<FS_TREE>/home
265	3637	258		<FS_TREE>/home/alex/.local/share/virtualbox_vms
295	5046	5		<FS_TREE>/root
259	5044	5		<FS_TREE>/snapshots
308	3813	259		<FS_TREE>/snapshots/pacsnap/201706152155
309	3929	259		<FS_TREE>/snapshots/pacsnap/201706181558
310	4147	259		<FS_TREE>/snapshots/pacsnap/201706222329
311	4216	259		<FS_TREE>/snapshots/pacsnap/201706251224
312	4459	259		<FS_TREE>/snapshots/pacsnap/201706300109
314	4517	259		<FS_TREE>/snapshots/pacsnap/201707011039
315	4665	259		<FS_TREE>/snapshots/pacsnap/201707030103
316	4796	259		<FS_TREE>/snapshots/pacsnap/201707040120
317	4936	259		<FS_TREE>/snapshots/pacsnap/201707050129
319	5044	259		<FS_TREE>/snapshots/pacsnap/201707060103
https://t.me/atvva
У меня тоже btrfs уже более трех лет работает - никаких проблем. И снапшотами активно пользуюсь для контейнеров - для этих целей cow вообще незаменимая вещь.
COW - это не специфическая фича btrfs. COW, как говорится, и в Африке COW. Поэтому какая-то конкретная ссылка на её реализацию в этой файловой системе вам не поможет, пока вы не поймёте её принципиальное преимущество. Википедия и гугл вам в помощь.
вопрос по снимкам.
условие:
есть 1.5Т раздел, занят файлами 1Т, делаю снимок и удаляю все файлы.
вопрос:
сколько свободного места останется на винте?
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
сколько свободного места останется на винте?
0.5T.
https://t.me/atvva
A.T.W.A., благодарю, я так и думал...
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
Хм. 20 гигов на btrfs это не много:) Но для арча где одна лишь система, с вынесеным home это достаточно. Правда у меня 40 гигов, 22 забито.

Но не об этом.Вроде с COW пока проблем не замечаю.
 
Зарегистрироваться или войдите чтобы оставить сообщение.