Sziasztok!
Van 2x16 TB HDD-n egy "Backup" pool, azon belül további 7 zvol (1-1 TB quota-val). A dedup és a compress a Backuptól öröklődik a zvoloknak.
6-7 TB a helyfoglalás, de (7x) 180 nap inkrementális mentést is (tehát több 100 millió fájlt) tartalmaz a ZFS mirror.
Szeretném a dedupot megszüntetni.
2 lehetőséget látok erre, de nem tudom, melyik működhet és ha mindkettő, akkor melyik gyorsabb/egyszerűbb?
1. Van egy másik ZFS pool (nVME SSD-ken mirror) ebben a gépben 2-2,5 TB szabad hellyel. Kikapcsolom a dedupot a Backup poolon, egyesével lementem rsync.kel az nVME-re a zvolokat, megszüntetem, majd újra létrehozom őket és vissza rsync-elem a mentéseket.
2. Kiveszem a mirrorból az egyik HDD-t, létrehozok rajta egy új ZFS (féllábú) mirrort és átmásolok mindent rsync segítségével az új poolra. Ezután megszüntetem az eredeti Backup poolt és a HDD-t hozzáadom az új mirrorhoz.
Mindenről van mentés máshol is, de jó lenne, ha nem hálózaton kellene minden adatot átmásolni.
Mit javasoltok? ezek közül/helyett a dedup megszüntetésére?
Szerk.: Az 1. variációval sikerült megszüntetni a dedupot.
Köszi minden érdemi hozzászólást!
- 442 megtekintés
Hozzászólások
A dedup ugye filerendszer-szintű beállítás, bármikor kikapcsolhatod. Utána csak át kell helyezned a file-okat, akár másik directoryba, és elmúlik a dedup.
Vagy nem helyezel át semmit sehova, pár hónap múlva amúgy is törődnek a régi adatok, az újak meg már dedup nélkül jönnek letre.
- A hozzászóláshoz be kell jelentkezni
Igen, ezt tudom, de nem szeretnék még pár hónapig éjszakai riasztásokra ébredni (ha egyáltalán ettől fagy le a szerverem...).
Eezért lennék túl rajta minél hamarabb.
- A hozzászóláshoz be kell jelentkezni
Ha "csak" az a baj, hogy elfogy a memória, szerintem elég kikapcsolni a dedupot, mert akkor már nem kell dedup táblát építgetnie. De fixme :) Egy próbát megér.
- A hozzászóláshoz be kell jelentkezni
# zpool status -D
pool: Backup
state: ONLINE
scan: scrub in progress since Sun Jun 12 00:24:01 2022
6.07T scanned at 418M/s, 2.56T issued at 176M/s, 6.30T total
0B repaired, 40.58% done, 06:11:47 to go
config:
NAME STATE READ WRITE CKSUM
Backup ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-TOSHIBA_MG08ACA16TEY_4150A0SUFVNG ONLINE 0 0 0
ata-ST16000NM003G-2KH113_ZL2EAG2B ONLINE 0 0 0
errors: No known data errors
dedup: DDT entries 21237909, size 2.27K on disk, 750B in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 19.2M 2.32T 2.29T 2.29T 19.2M 2.32T 2.29T 2.29T
2 641K 64.6G 53.3G 53.5G 1.36M 139G 113G 113G
4 383K 41.8G 34.6G 34.7G 1.65M 183G 149G 149G
8 49.9K 4.91G 3.52G 3.54G 479K 46.1G 32.2G 32.4G
16 16.1K 1.61G 869M 876M 346K 34.7G 17.9G 18.1G
32 6.72K 729M 328M 331M 296K 31.4G 13.8G 13.9G
64 8.19K 995M 380M 381M 792K 94.3G 36.2G 36.3G
128 820 77.8M 40.4M 40.7M 136K 12.5G 6.51G 6.57G
256 337 25.3M 9.89M 10.1M 122K 9.24G 3.61G 3.67G
512 311 26.1M 14.7M 14.9M 222K 18.9G 10.9G 11.0G
1K 65 950K 254K 368K 93.9K 1.16G 335M 505M
2K 29 164K 40.5K 116K 87.8K 458M 122M 351M
4K 25 158K 34.5K 100K 130K 724M 180M 521M
8K 13 13.5K 13.5K 52K 141K 153M 153M 562M
16K 10 12K 12K 40K 213K 286M 286M 851M
32K 6 3K 3K 24K 236K 118M 118M 944M
64K 5 2.50K 2.50K 20K 448K 224M 224M 1.75G
256K 1 512B 512B 4K 447K 223M 223M 1.75G
Total 20.3M 2.44T 2.38T 2.38T 26.3M 2.88T 2.66T 2.67TNéhány nappal ezelőtt már kikapcsolta, de ma ismét lefagyott a szerver.
- A hozzászóláshoz be kell jelentkezni
A DDT megmarad, nem lehet kikapcsolni, ha 1x bekapcsoltad.
- A hozzászóláshoz be kell jelentkezni
Meglátjuk...
Szerk.:
Már alakul...
# zpool status -D
pool: Backup
state: ONLINE
scan: scrub repaired 0B in 1 days 18:33:48 with 0 errors on Mon Jun 13 18:57:49 2022
config:
NAME STATE READ WRITE CKSUM
Backup ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-TOSHIBA_MG08ACA16TEY_4150A0SUFVNG ONLINE 0 0 0
ata-ST16000NM003G-2KH113_ZL2EAG2B ONLINE 0 0 0
errors: No known data errors
dedup: DDT entries 548505, size 87.9K on disk, 28.4K in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 498K 61.8G 60.7G 60.7G 498K 61.8G 60.7G 60.7G
2 6.14K 566M 448M 451M 13.2K 1.14G 915M 922M
4 31.8K 3.94G 2.42G 2.42G 178K 22.1G 13.2G 13.2G
8 62 7.11M 2.79M 2.81M 522 58.6M 23.4M 23.6M
16 7 514K 18K 28K 151 12.0M 422K 604K
32 3 1.50K 1.50K 12K 153 76.5K 76.5K 612K
256 1 512B 512B 4K 426 213K 213K 1.66M
4K 1 512B 512B 4K 4.52K 2.26M 2.26M 18.1M
Total 536K 66.3G 63.5G 63.5G 694K 85.0G 74.8G 74.8G
- A hozzászóláshoz be kell jelentkezni
ránézésre a ddt ott van tovabbra is
- A hozzászóláshoz be kell jelentkezni
Nah, végeztem:
# zpool status -D
pool: Backup
state: ONLINE
scan: scrub repaired 0B in 1 days 18:33:48 with 0 errors on Mon Jun 13 18:57:49 2022
config:
NAME STATE READ WRITE CKSUM
Backup ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-TOSHIBA_MG08ACA16TEY_4150A0SUFVNG ONLINE 0 0 0
ata-ST16000NM003G-2KH113_ZL2EAG2B ONLINE 0 0 0
errors: No known data errors
dedup: no DDT entriesAz előző bejegyzéssel csak szemléltetni akartam, hogy ahogy haladok a zvolok oda-vissza másolásával, úgy fogy a DDT bejegyzések száma és mérete. Akkor még 1 zvol volt hátra, amivel most véheztem.
- A hozzászóláshoz be kell jelentkezni
Már pedig ez máshogy nem megy. Még btrfs-en sem. Bekapcsolni be lehet menet közben a dedup-ot, de az csak a később írt fájlokra, mappákra fog vonatkozni, azoknál már figyelembe veszi a fájlrendszer. A korábbi adatokat csak úgy, ha újraírod, átmásolás, újraírás. Ez ilyen műfaj sajnos, mindig is ilyen volt, ilyen lesz.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Tisztában vagyok azzal, hogyan működik a dedup a ZFS-en. Én arra reagáltam, hogy kolléga azt (is) javasolta, hogy a dedup kikapcsolása után hagyjam hónapok alatt "magától kikopni" a dedupot, amikor a régi fájlok törlődnek, az újak meg már dedup nélül jönnek létre.
Erre írtam, hogy most megcsinálom az adatmpzgatást, hogy megszabaduljlak e deduptól, nem várok hónapokig, míg magától "megszűnik" a deduplikált adat.
- A hozzászóláshoz be kell jelentkezni
Egy kis pontosítás:
"Van 2x16 TB HDD-n egy "Backup" pool, azon belül további 7 pool (1-1 TB quota-val). A dedup és a compress a Backuptól öröklődik az al-pooloknak."
Itt gondolom set-ekre gondolsz. Backup pool (zpool parancs) és 7 set (zfs list parancs).
Amit én javasolnék ha van elég hely: zfs send-receive elvileg működik poolon belül. Tehát először dedup kikapcs, majd zfs send receive-vel átmásolod a set-eket, a régieket törlöd és átnevezed az újakat a régi nevére.
- A hozzászóláshoz be kell jelentkezni
Köszönöm a pontosítást, igazad van.
A ZFS send/receive eszembe sem jutott, azt is köszönöm!
HDD-n belül nem lenne az pokolian lassú? Viszont az nVME-n létrehozott set-re át-, majd visszaküldhetném rsyncelés helyett... (igazából kérdezem, sosem használtam még, csak olvastam a send/receive-ről)
- A hozzászóláshoz be kell jelentkezni
Sokkal gyorsabb mint a bármilyen fájl alapú eszköz (pl rsync), mert blokkonként szinte szekvenciálisan olvasva viszi át az adatot. De persze az nvme-s megoldás is tökéletesen működik.
- A hozzászóláshoz be kell jelentkezni
Javítva
- A hozzászóláshoz be kell jelentkezni
ha pontosak akarunk lenni: a dedup blokk alapu, nem FS.
Szerintem send-recieve lesz a jo megoldas, akar gepen belul.
Amugy nem igazan szerencses mirrort epiteni ketfajta lemezbol, ha van ra lehetoseg legyen egyforma.
- A hozzászóláshoz be kell jelentkezni
Van, aki szerint célszerű különböző fajtából építeni.
- A hozzászóláshoz be kell jelentkezni