Várható fájlméretek kb 3 mega maximum, de ez többezer akár naponta is, amit folyamatosan kell olvasni a meghajtóról, egyidőben akár 3-400 darabot is, előfordulhatnak rövidebb videók is ezek mellé, amiknek a hossza tervezetten nem több, mint 10 mega.
Melyik fájlrendszert javasoljátok erre a feladatra, illetve melyik fájlfeltöltés-letöltési protokollt?
- 923 megtekintés
Hozzászólások
Nem értem, hogy mi itt a kérdés. Kb. a FAT fájlrendszeren kívül bármelyik lazán tudja ezt. Vagy erősen limitált hardveren kell tudnia? A legtöbb disztribucióban alapértelmezett ext4 lazán kezeli ezt. Ha van valamilyen különleges szempont, akkor érdemes mást választani, pl. btrfs (bár nem tudom jelenleg az hogy áll), ZFS stb.
A fent leírt terhelésbe semmi különleges nincs, tök átlagosnak számít egy fejlesztői gépen és eddig sose volt gondom az ext4-gyel.
- A hozzászóláshoz be kell jelentkezni
nekem BTRFS-sel még nem volt szerencsém sosem :-( . mindig korrupt fájlok és teljes linux-újratelepítés lett a vége amikor azt választottam a desktopomon...
EXT4 párti vagyok :-)
Airconditioned terminal, do not open Windows.
- A hozzászóláshoz be kell jelentkezni
Hát, nem is a fájlrendszer az első kérdés, hanem a hardver, ami ez ki tudja szolgálni... Egy időben 3-400 fájlművelet ennyi darab különböző állományon? Ez alá sima HDD nagyon sovány lesz, valami SSD meghajtókból álló RAID10 tömbben kell elkezdeni gondolkodni szerintem. Aztán ha megvan a megfelelő teljesítményt kiszolgálni tudó hardver, akkor érdemes arról beszélni, milyen FS és volume kezelő legyen felette.
- A hozzászóláshoz be kell jelentkezni
Szerintem túlmisztifikálod. Ez szerintem kb egy képgaléria :)
- A hozzászóláshoz be kell jelentkezni
3MByte ~ 24MBit. Ha egy ilyen képet 0.5sec alatt le akarsz küldeni akkor kell overheaddel mindennel cca 55-60Mbit/sec per kép. felszorozva 300-al az 18 000MBit/sec. Innentől nem triviális.
- A hozzászóláshoz be kell jelentkezni
Az lehet, de az OP azt írta, 3 MB-os méretű állományokból egyidőben 3-400 darabot olvasnak fel.
Lehet, hogy egy webes képgalériáról van szó, de akkor hibás az eredeti paraméter megadás. :-)
- A hozzászóláshoz be kell jelentkezni
Nyilván. De én arra tippelnék, hogy az pontosan azt jelenti, hogy ki lehet választani a lapozón az egyszerre százat, és lehet, hogy lesz, hogy akár 2 ember is nézi az oldalt így :)
- A hozzászóláshoz be kell jelentkezni
Hát, nem lenne példátlan, ha a kérdező jelentősen túlbecsülné az igényével a valóságot. De remélhetőleg az OP pontosít, ha szüksége van igazi válaszra.
Pedig már kezdtem tervezni alá egy Kubernetes alapú megoldást, ami dinamikusan skálázódik ilyen felhasználásra. :-D
- A hozzászóláshoz be kell jelentkezni
Nekem az a tapasztalatom, hogy többségében ha valóban nagy igény lesz, akkor aki kérdez, jobban képben van...
- A hozzászóláshoz be kell jelentkezni
Napi több ezer fájlról beszélsz. Az semmi. Folyamatosan kell olvasni --> ez csak RAM kérdése. A linux kernel elég jól kihasználja a szabad RAM-ot pufferelésre, prefetchre.
Szóval én ezt az egészet úgy értelmeztem, hogy napi 1-2 ezer fájlt kell írni (ami nem sok ilyen apró fájlokkal), de sokszor vissza vannak olvasva. Ha ezt nem tudja egy 10 éves XEON megcsinálni elég RAM-mal, akkor kihajítom a fájlszerveremet. ;-) De konkrétan ezt megcsinálja az 5 éves workstation laptopom is.
- A hozzászóláshoz be kell jelentkezni
Érdekes, hogy Te is ebbe kötsz bele. De ami írtam, megállja a helyét. Tudni kell milyen lesz a hardver, és akkor lehet továbbiakról beszélni. Ta egy VPS-ben futtatná havi 590 Ft-ért, 1 vCPU, 512 MB memória mellett, akkor az kevés lesz erre a feladatra, FS-től és Linux kernel verziótól függetlenül.
A különböző értelmezések miatt egyértelmű, hogy hibás/nem elégséges a specifikáció.
- A hozzászóláshoz be kell jelentkezni
Így van, nincs pontosan meghatározva, hogy milyen környezetben kell ezt teljesíteni.
- A hozzászóláshoz be kell jelentkezni
Itt az a baj, hogy nem csak a környezet nincs meghatározva, hanem semmi, se a hardver, se a felhasználás, milyen fokú rendundancia és egyéb funkciók kellenek (tömbök/pool, snapshot, röptömörítés, deduplikáció, titkosítás, stb.). Így ilyen általánosságokat puffogtatva, az ismeretlenben én natúr ext4-et ajánlanék. Ősi kernelek is kezelik default, gyors, kicsi az overheadje, nem véletlen ez a default a disztrók 99,99%-án. Lehetőleg SSD-ről, elég RAM-mal, hogy tudjon belőle a kernel cachel-elni. De bármilyen más modern fs megfelelhet a célnak, csak lehetőleg ne szutyok FAT-ág, NTFS, ReFS, egyéb proprietary/elavul szemét legyen.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Mekkora a tervezett aktív össz kapacitás?
Mert ha relatív kicsi, akkor még RAMDISK is bejátszhat, annál kevés gyorsabb dolog létezik.
- A hozzászóláshoz be kell jelentkezni
Szinte barmit, ami alatt SSD van. A HDD-n fog elhasalni ez ilyenfajta terheles mellett, nem a filerendszeren.
- A hozzászóláshoz be kell jelentkezni
Mivel kérdezted, csak is ext4!
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
- A hozzászóláshoz be kell jelentkezni
Zavar van az erőben.
Ha a fenti értékek /nap értendők és folyamatosan, ebben az ütemben bővülnének, akkor ez nem egy gép, hanem egy elosztott adatbázis- vagy filerendszer- vagy object store-cluster.
Ha meg nem bővül, akkor meg csak RAM kérdése.
- A hozzászóláshoz be kell jelentkezni
XFS -t ajánlok, sok kis file-ra.
És ide kérem, hogy akik nem ajánlják, akkor miért nem !
1920. augusztus 01. a Magyarországi Tanácsköztársaság vége.
1918. március 21. – 1920. augusztus 01. Magyarországi Szocialista Szövetséges Tanácsköztársaság.
Nagyon nagy történelmi bűn, hogy létrejöhetett Magyarországon, 1918-ban a tanácsköztársaság.
- A hozzászóláshoz be kell jelentkezni
Szerintem, mivel kérdezte nem sok tapasztalata van a témában, ergo ha pl. az első héten lesz egy áramszünet, akkor lehet új topicot nyit, hogy "Hová tűntek az adataim XFS alatt"
Szerettem, használtam sokáig (ext4 előtt), de egyezzünk meg abban, hogy egy szünetmentes (azért gyors, mert durván megy a cache) és némi tapasztalat az xfsprogs használatában kellene, szemben az ext4-gyel.
Ezek alapján ma már én sem lennék a különbségen annyira elájulva, hogy xfs-t használjak:
https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystem…
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
- A hozzászóláshoz be kell jelentkezni
A kérdésekre válaszolva, alapvetően egy olyan szervert építek hamarosan, ahova fel és ahonnan le is töltenek majd képformátumokat, napi pár ezer egyelőre a terv, egyidőben 300, 3 MB-os file ami esélyes írásra és olvasásra, hogy ebből mennyi az írás és mennyi az olvasás, azt nem tudom még. Alapvetően a szerverben egyelőre 4GB RAM és 8GB swap file lesz terv szerint, sajnos a processzor nem izmos, 2 magos, celeronnal súlyosbított, 1,7 Ghz processzorral, később ezt muszáj lesz erősíteni.
- A hozzászóláshoz be kell jelentkezni
A naponta több ezer, illetve egyidőben akár 3-400 úgy értendő, hogy a nap nagy részében láblógatás van, de néha-néha bedurran egy-egy spike?
- A hozzászóláshoz be kell jelentkezni
Igen, rendszertelen lesz várhatóan a terhelés.
- A hozzászóláshoz be kell jelentkezni
Miután felpluszegyezted a szalvéta hátán végzett kalkulációmat, ezek szerint nagyjábol helyesen számoltam.
Na, ez a gép sehogy sem fog kihajtani 18GBit/sec -et.
- A hozzászóláshoz be kell jelentkezni
Elég 9et, mert 1s nem fél :D
- A hozzászóláshoz be kell jelentkezni
mit jelent az, hogy egyidőben?
- A hozzászóláshoz be kell jelentkezni
Azt jelenti, hogy 1 mp alatti olvasás és/vagy írás mennyisége.
- A hozzászóláshoz be kell jelentkezni
Mekkora a hálózat sávszélessége end-to-end? Én ebből indulnék ki, utána jöhet a szerver erőforrás-igénye.
- A hozzászóláshoz be kell jelentkezni
Egy kétmagos Celeronnal 1,7 GHz-en?! Még a 100 Gb is elég lehetetlennek tűnik…
- A hozzászóláshoz be kell jelentkezni
Mondjuk tud SATA 3-at (nemtudjuk).
SATA III (revision 3.x) interface, formally known as SATA 6Gb/s, is a third generation SATA interface running at 6.0Gb/s. The bandwidth throughput, which is supported by the interface, is up to 600MB/s.
- A hozzászóláshoz be kell jelentkezni
sok kis filera regen a reiserfs volt a nyero, mostanaban mar a btrfs.
io protokollnak en http(s) hasznalnek, post/get valamilyen wsgi-vel, esetleg webdav.
- A hozzászóláshoz be kell jelentkezni
Miért jó (jobb) a btrfs kis fájlokhoz?
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
- A hozzászóláshoz be kell jelentkezni
b-tree
- A hozzászóláshoz be kell jelentkezni
Ebben valószínűleg nem a fájlrendszer lesz a szűk keresztmetszet, úgyhogy az általad választott disztribúció default fájlrendszerét javaslom. Ahogy nagyjából mindenre, amíg nincs valami különös körülmény, ami miatt ez nem lenne jó...
- A hozzászóláshoz be kell jelentkezni