Keresés

Hirdetés

Új hozzászólás Aktív témák

  • janos666

    nagyúr

    LOGOUT blog

    A gentoo handbook szerint pötyögtem végig mindent. Az alapok mellé még egy xfce4-et telepítettem, ami most parancssoros bejelentkezés után startx-el szépen indul és működik, de slim-el bejelentkezve csak egy vastag X kurzor fogad fekete háttéren.
    Tippre mit ronthattam el, és mi lenne a megoldás (olyan, ami automatikusan be tud léptetni, mert áramszünet után is magától fel kéne majd állnia a rendszernek, és futnia kell az X-nek is).

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    Ez vajon szándékos feature, ha pár napja két Gentoo ~amd64 rendszer egyszerre (vélhetően az automatára időzített rendszerfrissítés után) úgy döntött, hogy többé nem engednek be SSH-val root user-ként jelszóval, csak RSA kulccsal?

    Van egy NEWS, hogy megszűnt a DSA kulcsok támogatása az OpenSSH-ban, de van ennek köze a "keyboard-interactive" beléptetéshez? (Odaírhatták volna pár szóban a butábbaknak, ha igen, pl. "Ami a jelszavas beléptetést is érinti.")

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    Gentoo-val lehet most problémamentesen ZFS root-on boot-olni EFI-stub kernellel, initramfs nélkül, ha beépítettem a kernelbe (nem csak loadable modulként van hozzá) az OpenZFS drivert?

    Ezzel minden ugyan úgy maradna, mint most, az egyetlen változás az lenne, hogy egy friss mentés után Btrfs-ről ZFS-re váltanék az SSD-n, visszaállítanám a rendszerfile-okat, majd szükség szerint módosítanám a kernelbe mentett hivatkozást, hogy hol találja a root-ot, ami jelenleg a GPT partíció ID-re hivatkozik (tehát talán még maradhatna is, mert nem kell megváltoznia az ID-nek, a kérdés csak az, hogy ZFS-nél hogy működne ez...).

    Bár alapvetően csak konkrétan a radi5/raid5/raid5 (data/metadata/system) profilos Btrfs-ből lett elegem (talán írok majd erről egy blogbejegyzést, hogy miért, de hosszú) a viszonylag nagy méretű adattárolásra használt HDD-ken, az SSD-n szépen dolgozik single/single/single profillal a rendszerfileok alatt, de az egységesség kedvéért (főleg, hogy a cache kezelésük is teljesen független, így kvázi egymással versengenek a szabad RAM-ért az ARC és a pagecache, illetve épp a cache vezérlés paraméterezhetősége pont egy olyan dolog, ami a single/raid profiltól függetlenül is jobban tetszik OpenZFS-nél Linux alatt, mint a Linux kernel általános paraméterezhetősége, amit nekem nem sikerült úgy beállítani, ahogy szerettem volna, de most az ARC van: csak metadata cache módba) szeretném a root filerendszert is lecserélni ZFS-re (csak ugyan így single módban, mint most van Btrfs-el, ebből nem lesz RAID profil), így elég legyen egyetlen filrendszer drivert betölteni (és egy ARC-ot tartani, nem egymás mellett ARC-ot és Linux-os pagecache-t is).

    Próbált már valaki ilyet?

    Egyrészt az OpenRC-ről van kételyem, ami úgy láttam szereti "kötelezően" újramount-olni a root-ot még akkor is, ha előtte már read-write módban mount-olta maga a kernel.
    Mikor átálltam erre az EFI-stub, EFI boot módra, és mindenképp kézileg, statikusan kellett megadnom a kernelnek a root filerendszer elérhetőségét (előtte a grub kezelte automatikusan), akkor próbáltam egyel tovább ugrani, és rögtön ott listázni a többi mount opciót, az fstab-ból pedig törölni a / bejegyzést (most elvileg már semmi sem használja értelmes módon...), de ez valamiért nem tettszett az OpenRC-nek. Nem olvastam végig, hogy mit akart, mert úgy volt beállítva, hogy azonnal újraindult és a naplózás még nem ment.
    A localmount scrip-et kéne ilyenkor törölnöm az RC listából, vagy a root nevű script-et is (vagy csak utóbbit)?

    A nagyobb kérdés viszont:
    - Hogy találja meg egy EFI-stub kernel a ZFS root-t?
    Ahogy elnézem, jelenleg a zfs-mount nevű rc script mount-olja nekem a HDD-kről a RAID-Z1 filerendszert (vagy valami fstab félével, amit automatikusan tölt fel, vagy scan-el egyet és betölt mindent, amit csak talál és sikerül), nem maga a kernel mount-olja automatikusan. Gondolom, hogy GRUB2-es boot-oláshoz ezért kell az initramfs, hogy scan-eljen és mountoljon minden ZFS-t a gépen, köztük a root-ot is. :U

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3449 üzenetére

    Bőséges válasz a hosszú kérdésre, de szerintem sok olyat is beleírtál, amit előre tisztáztam, hogy már tudom és akár most is is így van a gépemen (vagy annyit írtam róla, hogy lenne mit, de nem akarok túl sokat írni egy hsz-be). :D

    - fixen integrálva van a kernelbe a ZFS modul (amúgy is így szeretem, illetve előregondolkodtam)
    - A HDD-ken már most is RAID-Z1 dolgozik, így nyilván olvasgattam róla általánosságban. Ahogy írtam is, többféle WiKi-ből és FAQ-ból ollóztam össze, amit a ZFS-ről tudok, de azt hiszem tudok is már róla mindent, amit RAID-Z1 és adattárolás tekintetében szerettem volna.
    - A beépített kernel command line GPT PARTUUID alapján mount-olja a root-ot, ami így elvileg független a filrendszertől (és sok mástól is)

    Egyedül arról van kételyem, hogy ha most mindent így hagyok, és csak a filrendszert cserélem le, akkor azonnal működik tovább, vagy mást is módosítanom kell, illetve hogy működhet-e egyáltalán initramfs nélküli EFI stub kernellel a ZFS root-os boot-olás. Mert ahogy te is írod, csak GRUB2 + initramfs leírásokat találtam. Tehát nem tudom, hogy maga a kernel képes-e mount-olni a root-ot PARTID alapján, ha az ZFS, vagy ilyenkor kötelező az initramfs, ami végignézi a zpool-okat és kiválasztja közülük a root-ot.

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3449 üzenetére

    Rászántam magam erre: [link]
    genkernel --zfs --callback="module-rebuild rebuild" --no-compress-initramfs initramfs
    Bár a callback-et ki kellett hagynom (csak anélkül ment végig). Lehet, hogy ez volt a baj, de azt hittem, hogy csak azért nem tudott mit kezdeni magával, mert nincs modulom, amit újraépítsen (minden beépített).

    * Sourcing arch-specific config.sh from /usr/share/genkernel/arch/x86_64/config.sh ..
    * Sourcing arch-specific modules_load from /usr/share/genkernel/arch/x86_64/modules_load ..
    *
    * ERROR: --callback failed!

    Annyiból működött, hogy az initramfs töltődött be, és futtathatók voltak a shell-ben a zpool és zfs parancsok, viszont nem csak automatikusan nem tudta importálni a pool-t, de kézileg is hiába mutogattam neki a /dev/disk/by-id/ mappát is (ahol ott voltak a HDD-k), nem találta a pool-t. :(
    Csak libgcc pthread hibákat dobált, mikor próbálkoztam. :U

    Egyszer próbáltam magamnak összerakni egy egyedi Live-USB rendszert, ahol a genkernel felelt volna a teljes kernel konfigért, alapbeállításokkal (auto-modulosan), így initramfs-el együtt, de ott is nagyjából ugyan ez volt a probléma, hogy bár elérhető volt a btrfs parancs az initramfs shell-ben, de egyszerűen meg sem lehetett találni, nem még mount-olni a btrfs root-ot az initramfs-ből (hiába adtam oda a genkernel-nek a btrfs kapcsolót kézileg és próbáltam a genkernel-next verziót is több kernel verzióval, sohasem jöttem rá mit rontok el, bár hamar feladtam).

    Nem véletlenül ódzkodom tőle (initramfs), hanem nem értek hozzá. Noha inkább azért, mert nem is akarok, de épp azért nem akarok, mert eddig megvoltam nélküle... :))

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3452 üzenetére

    Szerintem már nem fog kiderülni, hogy sikerülne-e, mert mégis visszavágyom inkább Btrfs-re. :DDD (Most az a terv, hogy szétszedem a HDD-ket RAID5-ből külön RAID1-be és single-be, aztán átvariálom a mappáimat és azok helyhasználatát is ennek megfelelően, később pedig vagy újra visszatérek RAID5-re, ha kijavítják a hibáit, vagy RAID10 lesz belőle, ha találok még egy ugyan ilyen HDD-t olcsón -> ez az egyik előnye, hogy Btrfs-nél lehet oda-vissza mozogni, míg a ZFS statikus profilú).

    Mivel nagy munkának tűnt az initramfs, így inkább arra szántam időt, hogy nagyjából felmérjem a töredezettséget pár hónap használat után. A tapasztalatom pedig az, hogy bár kevéssé tördelődött szét, mint a Btrfs, és ami fontosabb, ez még kevéssé látszik meg a teljesítményén (főleg a metadata műveletek sebességén, ami egy idő után nevetségesen lassúvá vált Btrfs-el, de itt ilyen nem érzékelhető), de azért mégis csak töredezik (ami nem meglepő, csak a mértéke/hatása a kérdés), csak Btrfs-el erre legalább "drága" gyógyír volt (rendszeres recursive online defrag és metadata balance felváltva -- azért drága, mert sokáig tart és közben lassít, plusz nyúzza a lemezeket), itt gyakorlatilag nem igazán van (lehet próbálkozni a filerendszeren belül, vagy átmenetileg másik filerendszerbe és vissza mozgatással, de ilyenkor semmi garancia nincs a töredezettségre nézve, és idővel egyre csak nő, mintsem csökkenne a szabad terület töredezettsége akkor is, ha mindig ~25% szabad területet hagyok és egy ilyen mozgatás próba előtt felszabadítok némi extra helyet -> konkrétan csak ártottam vele, mikor kipróbáltam).

    Mivel ZFS-nél a metadata művelek nem lassultak látványosan, így egy L2ARC matadata cache sem jelent semmi számottevő gyakorlati hasznot (próbaképp adtam neki egy 80Gb-os SSD-t és noszogattam, hogy töltse fel minél jobban, de csak metaadatokkal), a szekvenciális műveleteken viszont látni a töredezettség hatását (ezen pedig nem segít számottevően sem az L1, sem L2 ARC, mert itt nem a metaadat töredezettség lassítja az adatműveleteket is, hanem maga az adattöredezettség látszik meg és "minden" nem fér be a cache-be, amit szekvenciálisan kéne elérni --- kivéve persze az írást, azt szépen cache-eli a RAM-ban,de olyat minden filerendszer tud, ha mást nem a kernel csinálja helyette :D).

    Szóval ja... :))
    A konklúzióm az, hogy alapjaiban jobb a ZFS, de nem tökéletes. Hiányzik belőle pár dolog, ami a Btrfs-nél elérhető. Az pedig önmagában véve probléma, hogy a Btrfs-nél a defrag nem csak elérhető, hanem kvázi kötelező, míg a ZFS szépen eldöcög nélküle, de a "drágán" karbantartott Btrfs összességében jobban fog teljesíteni a nap végén, mint a "magára hagyott" ZFS.

    Közben találtam egy érdekes bejegyzést arról, miként lehet lecserélni a FAT filerendszer modult bármi másra az UEFI firmware-ben: [link], amivel elvben lehet boot-olni szoftveres bootloader és FAT partíciók nélkül is (ha nem szignó-védett az alaplapi firmware). :)

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3454 üzenetére

    Szerintem semmi köze a disztróhoz, a mainline kernelben, illetve zfs git repóban van a lényeg, amibe a gentoo-source patchset csak minimálisan nyúl bele (sőt, alapvetően csak extra opciókat ad a menuconfig-ba, nem kényszereket teremt, vagy módosít) és ez is csak javasolt, de nem kötelező (használható a vanilla-source is). A ZFS kód azt hiszem közel 1:1 GIT-ről jött gentoo patch-ek nélkül (kivéve az extra useflag-eket), ahogy a Btrfs userland-hez sincs tudtommal érdemi patch a gentoo ebuild-ban.

    Ez szerintem kifejezetten jó is a gentoo-nál, hogy egyszerűen át tudom tekinteni, mi az, ami esetleg disztró-specifikus és mi nem, de általában jó tipp, hogy alapjáraton semmi sem az (mármint, ami "kintről jön", nem kimondottan a gentoo-hoz készül), és ha mégis, akkor sem megkerülhetetlen / kibogozhatatlan.
    Más disztróknál is utána lehet járni ennek, de általában az a kerülőút, hogy fogasd újra magadnak a disztróspecifikus patch-ek nélkül, ilyenkor pedig kényelmes, ha eleve forráskód alapú a disztró és a csomagkezelő.

    Amit a disztró tehet az esetleg az, hogy automatikusan átállítja az IO és/vagy CPU ütemezők paramétereit, esetleg beidőzít cron-al egy defrag-ot, netán btrfs balance-ot, stb.

    Vagy, ha messzebbre gondolkozunk, a Solaris megfordult a fejemben, de tudtommal oda, a zárt verzióhoz sem készült el soha ZFS-hez a Block Pointer Rewrite (és aki dolgozott rajta azt mondja örül is neki, hogy nem fejezte be és reméli más sem fogja helyette, mert "az lenne az utolsó feature", túlkomplikálná a jövőbeni változtatásokat), ami lehetővé tenné az online defrag-ot és a profilok közti online váltást (amiket a Btrfs már tud). Szóval ilyen szempontból ez most irreleváns. Linux-on relatívan zabálta a CPU-t a ZFS, de nem bántam, mert nem hiányzott másra (és talán jobban feküdt volna egy kicsi, de friss Intel CPU-nak, mint az öreg AMD csodának, amitől amúgy is épp szabadulni tervezek).

    A töredezettség pedig talán más mértékben alakul ki és/vagy érződik a megléte, de igazából nem a filerendszer, hanem a HDD "hibája". FAT32-t is használhatnék, azon is töredezetté válhatnak előbb-utóbb a file-ok, ha folyamatosan cserélődik egy részük, ez pedig mindig meglátszik az elvileg szekvenciális műveleteken, ha igazából mégsem azok, mert csattognak a HDD fejek a töredékekért. Ezért lehet hasznos a defrag (ez van EXT4-hez és Btrfs-hez is, ZFS-hez viszont nincs).

    Láttam a bcachefs-t. Az első benyomásom szerint semmi értelme, és többet ért volna valami olyasmit összerakni, mint a ZFS féle L2ARC. Csak nem is kell ARC, lehet sima "utolsó olvasat" cache, csak legyen olyan módja, ahol csak metadata megy rá, és ideális esetben kérésre automatikusan próbálja meg teletömni a metadata block-ok tartalmával hidegindítás után (reboot után melegen indulni biztos bonyolult, de ez nem tűnik annak).

    A legnagyobb balszerencsém a Btrfs-el csak az volt, hogy nekem pont a RAID-5 profil tűnik ideálisnak, míg a fejlesztők általában olyan szélsőségesen állnak a kérdéshez, hogy kétféle adat van, az egyiket minimum RAID1 (vagy 1+0) profillal tárolod és van róla off-site, off-line backup, 2+ példányban (a tenger alatti titkos bunkerben ólomszéfben, és a nagyi pincéjében is a dunsztosüveg mögött, a patkányfogó alatt alufóliában), vagy "szarsz rá" és olyan, mint ha egy sem lenne, szóval tök mindegy, akár a /dev/null-ra is küldhetné a filerendszer, szóval nem igazán támogatott a RAID-5/6. Már viszonylag rég volt viszonylag stabilnak tűnő állapotban (volt, aki állítólag legalább 1 éve használta), mikor használni próbáltam, de aztán kiderült, hogy tele van végzetes hibákkal, amikbe én bele is futottam (azóta is léteznek, nem prioritás a javításuk, de legalább már dokumentálták).

    Az extra hajlam és érzékenység a töredezettségre inkább csak olyan dolog, amit "tájékoztató és építő jelleggel" próbálok hangoztatni, nem olyan, ami miatt ne lehetne használni, hisz legalább működik a defrag és metadata balance (elvileg hibátlanul), amiket lehet automatizálni és az IO ütemezéssel csökkenthető az esetleges negatív mellékhatása is (bár gyakorlati szempontból ez lehetne alapszolgáltatás [mint pl. a zfs-nél a scrub-nak dedikált IO ütemező queue], de ez már részletkérdés, morogni lehet rajta, nem vizet választani vele).

    Amúgy igen. nem biztos, hogy ha szétszedem őket, akkor a szóló HDD-re is Btrfs megy, az talán EXT4 lesz (akár journal nélkül). Bár ezt már fejtegettem fentebb, hogy lényegében majdnem mindegy ilyen szempontból (csak a hibás RAID profilokra nincs gyógyír, minden másra igen és egyik filerendszer sem tökéletes más szempontból sem).

    Tudtommal nincs most ingyen semmi, ami olyan jellegű garanciákat kínál a konzisztenciára, mint a Btrfs és ZFS. Minden más vagy hagyományos RAID checksum-ok nélkül, vagy gyakorlatilag egy hagyományos, vagy checksum-olással kiegészített, esetleg paritásra épülő "okos backup" (pl. paritás nélkül ír fel először mindent, aztán kiegészíti a háttérben paritással vagy redundanciával és akár checksum-al is, de ez nem egy tranzakción belül történik, hanem későbbre tolva...). Ezektől ilyen szempontból szerintem minden visszalépés, vagy esetleg ugyan ez, csak más formában, de akkor olyanban, ami számomra nem tetszik, bonyolultabb, és/vagy elérhetetlen is (mint néhány speciális szerverekbe szánt megoldás, amit legfeljebb említésből ismerek, a működése "titkos" is vagy legalább is irreleváns, mert én úgysem fogom használni, főleg nem itthon).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3456 üzenetére

    Nem, most egy AMD 5600K (most cserélem majd Intel G4400-ra), és még ezen is számottevő a CPU igény, az E350 szerintem kevés lenne, hogy kiszolgálja a 3 lemezes RAID-Z módot 7200RPM HDD-kkel, főleg Samba-n keresztül, ami szintén éhes tud lenni.
    A ZOL oldalán is kiemelten közlik, hogy nincs teljesítményre optimalizálva, ami szerintem leginkább ebben merül ki, hogy tekeri a CPU-t, mert egyébként gyors (szóval csak relatívan lassú, hogy egységnyi munkához viszonylag sok CPU idő kell neki, de ha megkapja a CPU-t, akkor hasít, viszont gondolom minimum egyenes arányban nőne a CPU igény a HDD-k számával egy profilon belül, így simán lehet skálázódási gond, ha valaki egy gyenge kis CPU-ra [kevés mag, alacsony ipc/c] szeretne alapozni egy sok lemezes, vagy több szimultán terhelt pool-t).

    Az SSD nyilván egy más világ. Ha nem lenne probléma a költséghatékonyság, akkor nekem is kizárólag viszonylag lassú SSD-im lennének HDD-k helyett (a HDD szintű szekvenciális sebesség, de alacsony elérési idő megérne nekem mondjuk 1/2 felárat, de ma ez még sokkal több attól) és sohasem kéne foglalkozni a töredezéssel.
    Van, aki SSD-n is szokta defrag-olni a Btrfs-t (ez szerintem egyéni megítélés kérdése, van aki szerint őrült hülyeség, szerintem van benne némi ráció is, mert nem csak LBA terület értelemben, hanem maga a filerendszer is töredezik, miközben nem kopik olyan gyorsan az a NAND, hogy egyedül ez nyírja ki, ha néha átfuttatják - én ezt szerintem kihagynám, mint puszta hobbi, hacsak nem bizonyosodna be, hogy mégis érzékelhető, de elhinném, ha igen).

    Nem, rendszerszinten ~amd64 minden csomag (nem stable, de nem is GIT/9999) és gentoo-source (nem vanilla, mert szerintem itt minden gentoo patch hasznos, az experimental is, és legalább ennyi "késés" azért kell). Egyedül a ZFS jött GIT-ről, mint 9999-es csomagverzió, mert a ZFS számozott kiadásai lassabban jönnek gentoo-ra, mint a gentoo-source, így néha nem lenne kompatibilis a frissen lerántott kernellel (maszkolni kéne a kerneleket, de elvileg minden ZFS GIT commit tesztelve van, így elfogadható kompromisszumnak tűnik ez is).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    válasz F34R #3458 üzenetére

    Redundáns tömbben és hosszú garanciaidővel viszont ez majdnem mindegy, csak a várható / addig tapasztalt elhullási rátának megfelelően kell megválasztanod a redundancia szintjét és a hotspare-ek esetleges számát. Mivel általában szinkron módon írható/olvasható egy jobb féle SSD (nem csak a cache, hanem maga a NAND is), így nem is lohasztja le a tömböt egy-egy re-balance/build/silvering (ki hogy nevezi).

    Régen arról álmodtam, hogy mára legfeljebb kétszer annyiba kerül majd az olcsó NAND (akkor nem tudhattam, hogy a 3D TLC NAND lesz a nyerő) és akkor fogcsikorgatva meg lehet ejteni a majdnem teljes átállást, de ez lassabb folyamatnak bizonyult.

    ---

    Lenne viszont egy tényleg Gentoo-s kérdésem is. :D

    Van valami hatékony módszer a rendszer "tisztítására" azon kívül, hogy felhúzok egy szűz rendszert egy átmeneti új filerendszerben (vagyis inkább subvolume/dataset-ben, stb), kézileg válogatva átviszem a hasznos beállításokat/file-okat a régiből, aztán cserélek, majd törlöm a régi root mappastruktúrát (/subvoleme-ot)?

    Olyasmikre gondolok, hogy bizonyos csomagok beránthatnak sok másikat (pl. mikor nem néz szét az ember a useflag-ek közt előre és egy apró diagnosztikai kütyü még MySQL-t, Apache-ot és levelezőszervert is telepít, de van hogy szimplán csak változnak a függőségek), és a portage ezeket el tudja távolítani, ha már nincs rájuk szükség, ugyanakkor hátrahagyhatnak különböző konfigurációs/átmeneti file-okat, amiket érthető módon nem pucol le a csomaggal együtt. (Mármint valami más megoldás, mint kézileg átnézni minden kis almappát, vagy figyelmen kívül hagyni ezeket, mert valószínűleg úgyis csak néhány Mb az egész, vagy annyi se).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • janos666

    nagyúr

    LOGOUT blog

    Van valami parancs arra, hogy a teljes tree-t ellenőrizze le a portage MD5 checksum-okra, ne csak egy frissítéshez előkészített download quaranteen-t?

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Új hozzászólás Aktív témák