Názory k článku
Komentář: nespěchá se na Btrfs příliš moc?

Ak si za svoju historiu s linuxom pamatam vzdy musel niekto prist a zacat to pouzivat. Ext3, ext4, ReiserFS vzdy davali do customer distribucii (rozumej Fedora) na otestovanie uzivatelom. Vzdy da vyskytli pripady 'odchodu' celeho FS aj ked mali opravne utility.
V kazdom pripade ked uz to nebude tak dlho trvat tak by som na ten FSCK pockal.

To je zaujimave, COW by na SSD nemal robit vaznejsie problemy takze mozno ten processing. Zvlastne. Ale tak zase ReiserFS je fakt odladena supa.

Aha dik, clovek cita co chce vidiet, asi to Sata som si precital ako SSD.

To je divne, ja BTRSfs mam a zda se mi v pohode, ale na 90% datech mam ext4
Vic se mi libi ZFS, protoze je tok na netappu, jeste tak umet beduplikaci a nasadim ho ;-) ... na linuxu mi nefunguje i kdyz jsem ji povolil.
BTRFS taky ujde, ale zase nema RAID SP/DP (jako ZFS), ale tak lze resit pres RAID4 nebo 5 ci 6

Uvazuji doma o strogae a zatim cekam, az klesnou disky, bud tam bude ZFS/BTRFS a kdyz jeste nebudou ve stavu, co po tom chci, tak na to kaslu a bude tam RAID5 a ext4

ZFS deduplikaci ma, i kdyz mnohem drive ji mel FFS/UFS diky Epitome, nicmene ZFS a deduplikace nejde doma moc dohromady:

RAM Rules of Thumb

If this is all too complicated for you, then let's try to find a few rules of thumb:

For every TB of pool data, you should expect 5 GB of dedup table data, assuming an average block size of 64K.
This means you should plan for at least 20GB of system RAM per TB of pool data, if you want to keep the dedup table in RAM, plus any extra memory for other metadata, plus an extra GB for the OS.

http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe

Coz je smutna pravda.

Hammer FS deduplikuje i s 256MB RAM naprosto bez problemu

Pokial viem NetApp pouziva svoj vlastny suborovy sytem (nie ZFS - s Oracle boli v sudnom spore o patenty).

JJ, NetApp bezi na FreeBSD a wafl 100% proprietarni. Kvuli designu toho fs se Netapp soudi s kde kym.