[FreeBSD]fsck doet niets

[Verwijderd]

Hallo ik draai op een pc FreeBSD 5.1.2 rel2
Recentelijk ben ik tegen een raar probleem aan gelopen. In de partitie waar mijn /var op ligt zit iets fout getuige de output van fsck /var zie onder

code:

behemot# fsck -y /var
** /dev/ad0s1d (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=8264 (68 should be 64)
CORRECT? no

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=16547  OWNER=mysql MODE=100600
SIZE=2348 MTIME=Dec 30 12:14 2004
CLEAR? no

UNREF FILE I=16550  OWNER=mysql MODE=100600
SIZE=0 MTIME=Dec 30 12:00 2004
CLEAR? no

UNREF FILE I=16553  OWNER=mysql MODE=100600
SIZE=0 MTIME=Dec 30 12:00 2004
CLEAR? no

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

1492 files, 15772 used, 111066 free (458 frags, 13826 blocks, 0.4% fragmentation)

Het probleem is dat deze fouten niet gerepareerd worden. Wanneer ik boot in single user mode ziet fsck zelfs helemaal geen fouten. De fouten worden gevonden zodra ik de mysql server opstart maar ook dan heeft fsck -y /var geen enkel resultaat. Ook het mounten (in single user mode) van de /var en vervolgens fsck'en doet niets......

Iemand een idee?

[igmar]

Als je op vragen waarbij fsck vraagt of ie iets moet fixen 'no' als invoer geeft zal dat inderdaad resulteren in niet opgeloste problemen, maar daar vraag je dan ook zelf om. Begin eens met 'y' als reply op vragen.

[ Voor 7% gewijzigd door igmar op 30-12-2004 14:12 ]

[Verwijderd]

Daarom geef ik ook "-y" mee. Volgens de man page (als ik het goed gelezen heb) geeft hij dan op alle vragen een y. Overigens wanneer ik enkel fsck /var uitvoer zonder overige opties heb ik ook geen mogelijkheid om y in te voeren, hij vult standaard no in.....

Het probleem blijkt overigens ernstiger te zijn dan ik dacht. Wanneer ik mijn index probeer bij te werken met een portsdb -u of iets dergelijks krijg ik ook error. Waarschijnlijk omdat dit natuurlijk allemaal in een submab van /var staat.....

[0xDEADBEEF]

Hier heeft iemand een soortgelijk probleem; maar met /home.

Uit de 2e post aldaar:

its solved, i removed it from fstab, rebooted and checked it with fsck -y problems are all solved now, lets see if it works

Je fsck'ed nu met -y; gebeurd er meer als je het met -fy uitvoert ?

Man fsck:

-f Force checking of file systems, even when they are marked clean (for file systems that support this)

@igmar: read again

[igmar]

Verwijderd schreef op donderdag 30 december 2004 @ 14:51:
Daarom geef ik ook "-y" mee. Volgens de man page (als ik het goed gelezen heb) geeft hij dan op alle vragen een y. Overigens wanneer ik enkel fsck /var uitvoer zonder overige opties heb ik ook geen mogelijkheid om y in te voeren, hij vult standaard no in.....

Op linux werkt -y alleen met een automated check, en niet als je gedwongen wordt handmatig een check uit te voeren. Volgens de fsck manual van FreeBSD doet fsck alleen automatisch 'n' indien je -p meegeeft, en je geen write permissies hebt.

[Verwijderd]

gaan we maandag eens proberen. pc-tje staat niet hier.....

[Soultaker]

Je kan niet schrijven op een partitie die in gebruik is; daarom zegt fsck ook "NO WRITE" helemaal in het begin. Zorg dus dat 'ie niet gemount is (het beste daarvoor is dus in single user mode werken) en dan kun je gewoon -y gebruiken of zelf antwoorden geven.

De fouten die je krijgt zijn trouwens niet heel ernstig: het gaat om bestanden die verwijderd en niet meer in gebruik zijn (reference count op 0) maar die blijkbaar nog wel aanwezig zijn in de bestandsstructuur. Het zou me niet verbazen als dat normaal is binnen een live systeem en dat die na verloop van tijd (bijvoorbeeld bij het afsluiten van het systeem) vanzelf verwijderd worden. Dat zou verklaren waarom je in single user mode geen fouten meer tegenkomt.

Ook zou dit betekenen dat als je fsck op verschillende tijden uitvoert, je steeds over andere bestanden (inodes) foutmeldingne krijgt. Als dat zo is betekent het dus dat het bestandssysteem tussendoor niet 100% consistent is maar dat de bestaande problemen vanzelf opgelost worden.

[Verwijderd]

Dat laatste zal denk ik het geval zijn. Ik heb voor de grap op een andere pc een 5.1.3 installatie gedaan (schoon en op een gloednieuwe schijf) en ik zie exact hetzelfde gebeuren.... Wanneer ik fsck op verschillende tijdstippen draai is de output overigens wel exact hetzelfde

behemot# fsck /var
** /dev/ad0s1d (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=16592 OWNER=mysql MODE=100600
SIZE=2349 MTIME=Jan 6 13:41 2005
CLEAR? no

UNREF FILE I=16646 OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 6 10:11 2005
CLEAR? no

UNREF FILE I=16648 OWNER=mysql MODE=100600
SIZE=0 MTIME=Jan 6 10:11 2005
CLEAR? no

UNREF FILE I=25187 OWNER=root MODE=100644
SIZE=0 MTIME=Jan 6 10:11 2005
CLEAR? no

** Phase 5 - Check Cyl groups
1240 files, 14287 used, 112552 free (136 frags, 14052 blocks, 0.1% fragmentation)
behemot#

[ Voor 6% gewijzigd door Verwijderd op 06-01-2005 15:32 ]

[arikkert]

man fsck
geeft toch duidelijk info over fsck op al dan niet ge-mounte filesystems.

zie http://lists.freebsd.org/...004-September/008688.html voor
portsdb -u
errors

[ Voor 40% gewijzigd door arikkert op 07-01-2005 01:54 ]

[Soultaker]

arikkert schreef op vrijdag 07 januari 2005 @ 01:40:
man fsck
geeft toch duidelijk info over fsck op al dan niet ge-mounte filesystems.

Quote dan eens wat zinnigs, want ik zie het niet?

zie http://lists.freebsd.org/...004-September/008688.html voor
portsdb -u
errors

Wat heeft dat er in godsnaam mee te maken??

[AVL]

fsck op een live filesystem geeft deze fouten altijd, omdat a) het filesystem kan wijzigen tijdens de fsck en b) een bestandssysteem niet altijd consistent is tijdens het werken daarmee.

Deze foutmeldingen zijn overigens nog redelijk vriendlijk - op een druk filesystem krijg je er ook wat 'unexpected softupdate inconsistencies' bij.

Om een live filesystem te fsck'en, gebruik je dit commando:

code:

# fsck -f -B /filesystem

Heb je dan nog problemen, dan kan je hier terugkomen .

[ Voor 19% gewijzigd door AVL op 07-01-2005 19:28 ]