hi!
https://bugs.launchpad.net/ubuntu/+source/xfsprogs/+bug/772235
(tudom, szar az angolom)
Reportoltam egy ilyet. A lenyeg, hogy az xfs_check megeszi a memoriat,
belertve a swapot.
Lucid eseten OOM-mel elszall, de natty eseten csontra fagy meg a gep is
(ez utobbi lehet, hogy egy masik bug es altalaban az OOM killer megint
baszik helyesen mukodni).
Mas is tapasztalja ezt?
Ill. az erdekelne meg, hogy az Ubuntu-nal hogy megy, hogyan kezelik a
bug reportokat? Mi szamit surgosnek, mi nem? A velemenyem szerint ez
eleg szopo bug, ha masnal is igaz, akkor lenyegeben az xfs
hasznalhatatlan azokon a rendszereken. Ha az OOM killer is szar, az meg
meg kulon sulyos hiba.
10x
tompos
_______________________________________________________
linux-flame lista - linux...@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux-flame
> Reportoltam egy ilyet. A lenyeg, hogy az xfs_check megeszi a memoriat,
> belertve a swapot.
Ez valoban bugnak tunik (megpedig szerintem a kernelben, nem az
xfs_checkben). Workaround: futtasd ulimittel beallitott memoriakorlatokkal
az xfs_checket.
En mondjuk sose hasznalok xfs_check-et, csak xfs_repairt; azt probaltad?
Annak kifejezetten korlatozhato a memoriahasznalata a -m kapcsoloval.
(Oszinten szolva nem is nagyon ertem, mi ertelme van az xfs_checknek.)
Hogy mennyi memoria kell nekik, az fokent az ellenorzott fs-en talalhato
inode-ok szamatol fugg.
Amugy a freenode-on az #xfs csatornan ott vannak az xfs fejlesztoi es
szoktak valaszolni kerdesekre (ha jo napszakban teszi fel oket az ember).
Guy
--
Andras Korn <korn at elan.rulez.org>
Ethernet (n): something used to catch the etherbunny.
On 05/07/2011 02:50 PM, KORN Andras wrote:
> Ez valoban bugnak tunik (megpedig szerintem a kernelben, nem az
> xfs_checkben). Workaround: futtasd ulimittel beallitott memoriakorlatokkal
> az xfs_checket.
>
> En mondjuk sose hasznalok xfs_check-et, csak xfs_repairt; azt probaltad?
> Annak kifejezetten korlatozhato a memoriahasznalata a -m kapcsoloval.
> (Oszinten szolva nem is nagyon ertem, mi ertelme van az xfs_checknek.)
Kozben talaltam egy archivumot egy levelezesbol, amiben arra jutottak,
hogy igazabol a check mar nem is kellene, mert ott van a repair, kiveve
egy funkcionalitast, de azt majd belerakjak, viszont meg nincs benne.
Vmi btree ellenorzes? En annyira nem vagom a temat sajnos:/
Azt sem ertem, miert nem a klasszikus fsck.xfs terminologiat hasznaljak.
10x
tompos
> > En mondjuk sose hasznalok xfs_check-et, csak xfs_repairt; azt probaltad?
> > Annak kifejezetten korlatozhato a memoriahasznalata a -m kapcsoloval.
> > (Oszinten szolva nem is nagyon ertem, mi ertelme van az xfs_checknek.)
>
> Kozben talaltam egy archivumot egy levelezesbol, amiben arra jutottak,
> hogy igazabol a check mar nem is kellene, mert ott van a repair, kiveve
> egy funkcionalitast, de azt majd belerakjak, viszont meg nincs benne.
> Vmi btree ellenorzes? En annyira nem vagom a temat sajnos:/
> Azt sem ertem, miert nem a klasszikus fsck.xfs terminologiat hasznaljak.
Azert, mert nincs olyan eszkoz (jelenleg), ami userspace-bol vissza tudna
jatszani az xfs journalban tarolt tranzakciokat, marpedig ezt egy fsck-nak
tudnia kene. Ez szerintem az xfs legzavarobb tulajdonsaga jelenleg.
A fejlesztok azt mondtak, egyszer mar nekiugrottak, hogy belerakjak az
xfs_repairbe is a journal-lejatszast, es valami betaverzio keszult is ebbol,
de aztan abbamaradt, vagy valami. De szerepel a tervek kozott.
En irtam egy fsck_xfs scriptet, kb. az alabbi (elso parameter a blockdevice,
masodik a mountopciok -- csak akkor van jelentosege, ha kulso journalt
hasznalsz):
#!/bin/zsh
if [[ ! -b "$1" ]]; then
echo "fsck_xfs: $1 is not a block device. This is probably an error."
exit 1
fi
mountdir=/mnt/xfs_fsck/${1//\//_}
logdev=$(echo "$2" | sed -n '/logdev/{s/.*logdev=//;s/,.*//;p}')
[[ -n "$logdev" ]] && logopts="-l $logdev"
[[ -d "$mountdir" ]] || mkdir -p "$mountdir" || {
echo "Couldn't create '$mountdir'; you may have grave problems..."
exit $LINENO
}
mount "$1" "$mountdir" -o ${2:-noatime} || {
echo "mounting $1 failed. Please investigate."
exit $LINENO
}
umount "$mountdir" || {
echo "umounting $1 failed. Whoa!"
exit $LINENO
}
if [[ -z "$XFS_SKIP_FSCK" ]]; then
xfs_repair ${=logopts} "$1"
ret=$?
fi
xfs_admin -c 1 "$1" # Enable lazy-count on the fs
exit $ret
Guy
--
Andras Korn <korn at elan.rulez.org>
No, I'm from Iowa. I only work in Outer Space.
> A lenyeg, hogy az xfs_check megeszi a memoriat,
> belertve a swapot.
Orosz fórumokról szedtem össze, hátha hasznos valakinek itt is:
xfs nagyszámú 5-30 kb-os fileokkal nem igazán tudott anno dolgozni, ezen
állítólag sokat javítottak utolsó időben.
Lehet finomra tuningolni és akkor nincs korábbi 80%-os elmaradás EXT2-hez
viszonyítva.
xfs_check lényegében xfs_db szkriptelve.
xfs_check default paraméterekkel kéri 2 GB minden 1 TB-ra (gyakorlatból,
nincs leírva sehol sem).
20 TB xfs-en 8 GB RAM szerveren addig seggfaultolt, amíg elég nagy swap
területet nem kapott.
Érdemes nézegetni a http://xfs.org/index.php/XFS_Status_Updates oldalt.
--
Üdvözlettel, To complete the log-in procedure,
Cemasko Viktor. stare directly at the sun.
> Orosz fórumokról szedtem össze, hátha hasznos valakinek itt is:
>
> xfs nagyszámú 5-30 kb-os fileokkal nem igazán tudott anno dolgozni, ezen
> állítólag sokat javítottak utolsó időben.
> Lehet finomra tuningolni és akkor nincs korábbi 80%-os elmaradás EXT2-hez
> viszonyítva.
Ez szinte biztosan marhasag. :)
> xfs_check lényegében xfs_db szkriptelve.
> xfs_check default paraméterekkel kéri 2 GB minden 1 TB-ra (gyakorlatból,
> nincs leírva sehol sem).
Ez pedig egeszen biztosan marhasag, mert az xfs_check memoriafoglalasa nem
az fs meretetol, hanem az inode-ok szamatol fugg. (Az fs meretetol csak az
AG-k szaman at, es csak kicsit, szerintem.)
> Érdemes nézegetni a http://xfs.org/index.php/XFS_Status_Updates oldalt.
Ez igaz.
Guy
--
Andras Korn <korn at elan.rulez.org>
Double your clock speed - Plug into 220 volts.