Naplózó filerendszerek (journaling)

Összetett tárolási megoldás kialakítása

Sziasztok,

a következő problémához szeretnék segítséget kérni:

Az évek alatt felhalmozódott egy nehezen kezelhető adatmennyiség, amiben már nem bírok eligazodni. Tulajdonságai:

- kb. 200 GB, kis fájlokból álló kása (kódrészletek, műszaki dokumentáció, szakirodalom, stb.) + ?00 GB generálszar (zene, ilyesmi)
- Az állományok száma valószínűleg >100k.
- Nem vált be, hogy kitalálok egy okos könyvtárstruktúrát, mert a legtöbb fájlt több helyre is lehetne tenni.
- Az állományok nagyobb része nem igényel verziókezelést.
- Emellett az aktív munkák egy jelentős része gitben van tárolva (ennek a jelentőségéről ld. lejjebb)

Ennek a trágyahegynek a rendbetételéhez keresek valamilyen tárolási megoldást, az alábbi szempontrendszer szerint:

- A kidobás nem megoldás. Egy része szanálható volna de nem tudom, hogy melyik.
- Valamilyen SOHO megoldást keresek, de komolyabb is jöhet, ha máshogy nem megy.
- HW oldalról is szeretnék valamiféle robusztusságot (RAID?).
- Hálózatról elérhetőnek kellene lennie, ehhez gondolom kellene valami NAS-féle, ami legyen csendes és takarékos.
- A fájlrendszer is legyen robusztus, ill. támogassa az eddig felsorolt és az alábbi szempontokat.
- A fájlrendszer, vagy valamilyen réteg biztosítson context-based (vagy nem tudom hogy mi erre a jó kifejezés) felületet, pl. tagekkel, tehát, hogy ne egy bonyolult könyvtárszerkezetben kelljen túrni.
- A fájlok mozgatása legyen hülyeálló, vagy kényszerítse ki a rendrakást. Iszonyú rendetlen vagyok.
- A rendszer elemei legyenek egyszerű, kvázi-standard elemek, tehát ha valami beszarik, akkor standard eszközökkel is hozzá lehesen férni a fájlokhoz.
- Legyen könnyen backupolható.
- A fájlok egy részét időszakosan bárhonnan elérhetővé szeretném tenni. Tehát pl. egyes fájlokat fel lehessen tölteni egy felhős tárolóba és ezeknek szinkronizálása is legyen.
- Ezen kívül van ami git-ben megy, ami azért probléma, mert vannak fájlok, amiknek a gitben tárolt forrás mellett a helyük, de jó lenne, ha az említett context-based megoldás is megtalálná őket, ha keresek. Tehát git-integráció welcome, ha van.
- Jó lenne, ha ez a sok feature integrálódna a meglévő UI-be (bash, Gnome, stb.).

A vasra és a SW-re is várok javaslatokat, minden konstruktív ötletet szívesen veszek, az sem baj, ha nem teljesen az én elképzelésemet tükrözik. Olyan alternatív elképzelésekről is szívesen olvasnék, hogy pl. van-e valami tudománya annak, hogy hogyan lehet egy hagyományos könyvtárszerkezetet optimálisan kialakítani, stb.

[MEGOLDVA] EXT4 atmeretezesi problema

Adott egy kiserleti rendszer amin egy regi 80 gigas diszkre LVM-et tettem.
Minden tokeletesen mukodik de a mar meglevo ext4 particio atmeretezesevel bajban vagyok.
Kezdesnek egy 2 gigas volumet csinaltam ext4-re formazva, majd ennek a meretet probaltam megnovelni a kovetkezokeppen:


root@gw:/tmp# df -h /lvmteszt/vol01
Fájlrendszer           Méret Fogl. Szab. Fo.% Csatol. pont
/dev/mapper/proba-vol01  2,0G  1,2G  728M  63% /lvmteszt/vol01
root@gw:/tmp# umount /lvmteszt/vol01
root@gw:/tmp# lvresize -L 16G "/dev/mapper/proba-vol01"
File descriptor 7 (pipe:[7031]) leaked on lvresize invocation. Parent PID 3303: bash
  Extending logical volume vol01 to 16,00 GiB
  Logical volume vol01 successfully resized
root@gw:/tmp# resize2fs /dev/mapper/proba-vol01
resize2fs 1.42 (29-Nov-2011)
Please run 'e2fsck -f /dev/mapper/proba-vol01' first.

root@gw:/tmp# e2fsck -f /dev/mapper/proba-vol01
e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/proba-vol01: 62907/131072 files (0.0% non-contiguous), 311766/524288 blocks
root@gw:/tmp# mount /dev/mapper/proba-vol01 /lvmteszt/vol01/
root@gw:/tmp# df -h /lvmteszt/vol01/
Fájlrendszer           Méret Fogl. Szab. Fo.% Csatol. pont
/dev/mapper/proba-vol01  2,0G  1,2G  728M  63% /lvmteszt/vol01
root@gw:/tmp#

A vegen jol latszik hogy latszolag minden lefut hiba nelkul de az atmeretezes mar nem jott ossze neki.
Mit rontottam el?

lessfs - tapasztalatok?

Van nekünk némi adatunk az irodai szerveren. És kezd elfogyni a hely. A jelenlegi merevlemez árak mellett nem feltétlenül szeretnék új lemezbe beruházni.
Mivel az adatok egy jelentős része jól tömöríthető, és duplikáció is akad bőven, ezért gondoltam megpróbálnék valami tömörítős, dedupos megoldást.
Erre találtam a lessfs-t ami gonoszul FUSE, és gondolom ennek, meg pl. a tömörítésnek hála nem is túl gyors. De nem valószínű, hogy evvel együtt is szűk keresztmetszet lenne belőle (A hálózat lesz az).

A kérdés az lenne, hogy van-e valakinek tapasztalata vele.

soft RAID resync miért?

Sziasztok!

Az otthoni NAS-omban van 3 db diszk szoftveres RAID5-ben. Teljesen jól működik hónapok óta, de időnként számomra ismeretlen ok miatt újraszinkronizálja magát.

cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdd1[3] sdc1[1] sda1[0]
2930269184 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
[===============>.....] check = 77.1% (1130650424/1465134592) finish=138.4min speed=40274K/sec

unused devices:

Mi ennek az oka? Talán ez?

cat /etc/cron.d/raid-check
# Run system wide raid-check once a week on Sunday at 1am by default
0 1 * * Sun root /usr/sbin/raid-check

Mi történne, ha kikapcsolnám??? Vagy esetleg havira állítanám?

Előre is köszi a választ!

btrfs és a száguldó csigák...

Egy ideje használok btrfs-t a /home fájlrendszeremen, eleinte nem is volt vele baj, de most már komoly problémák vannak a teljesítményével. A /home nincs igazán túlterhelve:

/dev/sda6 12G 9,3G 1,4G 88% /home

Ezek mellett időnként nekiáll tekerni az sda6-ot, a leggyakoribb az alábbi pár processz, összeollózva több `iotop` kimenetből:

727 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [btrfs-submit-0]
736 be/4 root 0.00 B/s 0.00 B/s 0.00 % 87.95 % [btrfs-transacti]
6639 be/4 root 196.01 K/s 784.03 K/s 0.00 % 62.63 % [btrfs-endio-wri]
727 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [btrfs-submit-0]
736 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [btrfs-transacti]
6639 be/4 root 2.74 K/s 84.98 K/s 0.00 % 61.00 % [btrfs-endio-wri]
6639 be/4 root 94.82 K/s 189.64 K/s 0.00 % 30.83 % [btrfs-endio-wri]

Ez az IO terhelés 15-20-30 percig tart, addig a gép gyakorlatilag használhatatlan. Találkoztatok ilyesmivel? :)

Eléggé meggondolandó, hogy btrfs-t használjak ezek után.

ez mi miatt lehet?

Mindig így szoktam csinálni a fájlrendszer csökkentést, ahogy lejjebb mutatom. Eddig nem volt gond. Ez így hülyeség, és eddig csak szerencsém volt? Vagy ez most véletlen egybeesés, és ne törődjek vele? (A második fsck által talált hibák bizonytalanítottak el).


spark:~# mount
/dev/mapper/rd1-moging on /export/moging type ext3 (rw,noexec,nodev)
spark:~# df
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/rd1-moging
                      4.9G  1.5G  3.2G  32% /export/moging
spark:~# umount /export/moging
spark:~# e2fsck -f /dev/rd1/moging
e2fsck 1.41.3 (12-Oct-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/rd1/moging: 1816/645120 files (20.3% non-contiguous), 399117/1288192 blocks
spark:~# resize2fs /dev/rd1/moging 3G
resize2fs 1.41.3 (12-Oct-2008)
Resizing the filesystem on /dev/rd1/moging to 786432 (4k) blocks.
The filesystem on /dev/rd1/moging is now 786432 blocks long.
spark:~# mount /export/moging/
spark:~# df
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/rd1-moging
                      3.0G  1.5G  1.4G  52% /export/moging
spark:~# lvresize -L 3.4G /dev/rd1/moging
  Reducing logical volume moging to 3.40 GB
  Logical volume moging successfully resized
spark:~# resize2fs /dev/rd1/moging
resize2fs 1.41.3 (12-Oct-2008)
Filesystem at /dev/rd1/moging is mounted on /export/moging; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/rd1/moging to 891904 (4k) blocks.
The filesystem on /dev/rd1/moging is now 891904 blocks long.
spark:~# df
/dev/mapper/rd1-moging
                      3.4G  1.5G  1.8G  46% /export/moging
spark:~# umount /dev/rd1/moging 
spark:~# e2fsck -f /dev/rd1/moging
e2fsck 1.41.3 (12-Oct-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Directories count wrong for group #25 (14, counted=0).
Fix<y>? yes

Directories count wrong for group #26 (16, counted=0).
Fix<y>? yes

Directories count wrong for group #27 (19, counted=0).
Fix<y>? yes


/dev/rd1/moging: ***** FILE SYSTEM WAS MODIFIED *****
/dev/rd1/moging: 1816/451584 files (20.5% non-contiguous), 393045/891904 blocks

Linux rendszer pendriverol

Mennyire eletkepes gondolat egy Linux alapu servert pendrivera installalni, es arrol mukodtetni, hogy megmaradjanak a SATA csatlakozok a RAIDnek ?
Gondolok itt arra, hogy mekkora esellyel hibasodik meg a pendrive, vagy megy tonkre a mukodestol.

Igaz az, hogy erdemes ext2-vel hasznalni, vagy ezt is csak mondogatjak, de nem tamasztja ala bizonyitek ? (Allitolag a journaling nem tesz jot a flasnek, de a Google is ext4re valtotta az jffs-t a telefonjain, nem tudom mit gondoljak ezutan)

Ext4 partíció konvertálása NTFS partícióvá adatvevesztés nélkül, lehetséges?

A kérdés adott, arra lennék kiváncsi, hogy lehetséges e egy Ext4-es partíciót adatvesztés nélkül NTFS partícióvá konvertálni?
Egyrészt idő megspórolása miatt lenne érdekes, másrészt pedig azért, mert nincs helyem biztonsági mentést csinálni.

Köszi!

Attila

előző ext3 maradékának kinyerése

Sziasztok,

az egyik ügyfelem egy partícióját, amin korábban is ugyanúgy ext3 volt, véletlenül újraformázta és írt rá pár fájlt.

Szerintetek van esély valahogy visszaszerezni a korábbi fájlok maradékát?

Elindítva úgy érzem, a testdisk kevés lesz ehhez, olvasgattam ilyeneket:

http://www.linuxquestions.org/questions/linux-software-2/recover-format…

http://www.cgsecurity.org/wiki/Advanced_Find_EXT2_EXT3_Backup_SuperBlock

Ma estére szeretnék a közösség erejével jutni vele valamire. TI hogy állnátok neki?