Ssh ok mais sshfs bug !

Support Debian
#1

Salut à tous.

Je ne poste pas souvent sur le forum debian-fr, faut dire que j’ai rarement de soucis sous Debian qu’une recherche sur le net ne me permette de résoudre. Mais la je me retrouve devant un soucis sur lequel je cale, du coup je me permet de solliciter la communauté.

Utilisant deux PCs à la maison et craignant de perdre mes données par crash disque car incapable de gérer mes sauvegardes, j’ai investi dans un petit NAS, un Netgear Stora qui à l’avantage de tourner sous RedHat Linux ce qui permet de le modifier à sa guise.Trés satisfait jusqu’ici de ce NAS, je suis rapidement parvenu à mettre en place un accès sur le NAS via sshfs via le sshd d’origine de la machine qui couplé à des cables éthernet catégorie 6 donnait l’impression d’un disque local.

Depuis la copie d’un gros gros fichier (un dd d’un DVD), le NAS c’est mis à bugguer lors de la connection via sshfs. j’ai une belle “erreur d’entrée sortie”. Du coup, j’ai cherché pas mal, réinstaller ssh, sshfs, réinitialisé les clefs, réinitialisé le NAS, etc. Et je ne parvient toujours pas à corriger cette erreur.

Je parvient encore à me connecter via ssh, sans soucis , et même en graphique via nautilus, mais je ne retrouve pas le confort de sshfs, je veut donc corriger ce bug.

Je suis sous Debian Sid avec un pinning. Si l’un d’entre vous aurais une piste je suis preneur, avec un grand merci d’avance. :slightly_smiling:

#2

La première idée qui me viendrait à l’esprit serait de faire un fsck sur ton NAS.

#3

J’en avais entendu parlé mais je maîtrise pas encore.

J’obtient ceci:

-bash-3.2# fsck /dev/md0 fsck 1.39 (29-May-2006) If you wish to check the consistency of an XFS filesystem or repair a damaged filesystem, see xfs_check(8) and xfs_repair(8).

Avec toujours un erreur d’entrée sortie ensuite. On peut faire fsck sur un disque raid ?

Je continue à chercher la doc de fsck. :slightly_smiling:

#4

Mon petit garçon vient de se réveiller, je reprend mes recherches ce soir. :slightly_smiling:

#5

On peut faire fsck sur un disque raid ?
Oui

À la vue des messages d’erreur, la question que tu devrais plutôt tes poser est la suivante :
On peut faire fsck sur une partition xfs ?
Réponse : oui et non

$ man fsck.xfs

fsck.xfs(8)                                                        fsck.xfs(8)

NAME
       fsck.xfs - do nothing, successfully
DESCRIPTION
       fsck.xfs  is  called by the generic Linux fsck(8) program at startup to
       check and repair an XFS filesystem.  XFS is a journaling filesystem and
       performs  recovery  at  mount(8)  time if necessary, so fsck.xfs simply
       exits with a zero exit status.

       If you wish to check the consistency of an XFS filesystem, or repair  a
       damaged or corrupt XFS filesystem, see xfs_check(8) and xfs_repair(8).
#6

Cool ! ca ouvre une piste.

Je teste dès que j’ai le temps.

http://www.openstora.com/wiki/index.php?title=Prevent_unclean_filesystems_from_blocking_the_boot_process

#7

Bon ben un fsck programmé au démarrage ne donne rien encore. D’autant qu’on n’a aucun retour sur le bon déroulement du processus. Je continue mes recherches. Mais merci de ta piste syam, je vais l’explorer. :slightly_smiling:

#8

/var/log/fsck/ :wink:

#9

Tu nous dis avoir des messages d’erreur I/O , tu pourrais aussi t’inquiéter des disques et de leurs états SMART …
Nature des volumes en présence :
RAID de quel type ? logiciel ? matériel ? RAID1 RAID5? … LVM ?

Si tu veux réparer du xfs qui soit vraiment en sale état, oublie fsck, utilise xfs_repair.
Avant d’utiliser xfs_repair, assure-toi qu’il s’agisse bien de xfs et pas d’un autre fs.
Assure-toi aussi qu’un simple montage ne suffise pas.

xfs, généralement on le monte et la vérification est faite. On peut même y aller à coup de coupures sauvages répétées avant que ça ne pose l’ombre d’un problème.
Tente de le monter explicitement à la :

mount -t xfs /dev/md0 /point/de/montage

En cas de coup dur uniquement, on a recours à xfs_repair, fsck n’y peut rien.
fsck d’une partition xfs est une tromperie qui n’existe que pour des raisons de compatibilité.
Les logs de fsck sur xfs ne peuvent renseigner que de la réussite ou de l’échec de la tromperie.

$ cat /sbin/fsck.xfs[code]
#!/bin/sh -f

Copyright © 2006 Silicon Graphics, Inc. All Rights Reserved.

AUTO=false
while getopts “:aApy” c
do
case $c in
a|A|p|y) AUTO=true;;
esac
done
eval DEV=${$#}
if [ ! -e $DEV ]; then
echo "$0: $DEV does not exist"
exit 8
fi
if $AUTO; then
echo "$0: XFS file system."
else
echo "If you wish to check the consistency of an XFS filesystem or"
echo "repair a damaged filesystem, see xfs_check(8) and xfs_repair(8)."
fi
exit 0
[/code]

#10

Résolu après un bon moment. Je fonctionnais depuis uniquement via ssh dans nautilus, mais ça ne m’apportais pas le confort de sshfs.

En fait, seul le répertoire qui contenait mes données boguait via sshfs(tout ce temps pour m’en rendre compte), il m’a donc suffit de créer un autre répertoire, y déplacer mes données, renommer le répertoire fautif et le nouveau pour retrouver mon installation fonctionnelle.

Le répertoire fautif existe encore car il ne semble plus être considéré comme répertoire et ne veut donc pas être supprimé même avec un rm -fR ou rm -f. Mais il ne me gène pas tant que mes données sont gardées au chaud.

La solution était toute simple, mais il a fallu que je tombe dessus.