Deux notes cependant :
- Son utilisation requiert d'avoir monté la partition avec le support des attributs étendus ("user_xattr").
- Ce n'est pas un outil d'usage hebdomadaire, plutôt quelque chose à utiliser tous les un ou deux ans pour le principe (sauf si l'on a trop de fichiers sparses). Ceci dit, les utilisateurs actuels disent avoir ressenti un réel bénéfice, et n'ont généralement pas eu de problèmes.
En premier lieu, il cherche les "amis" du fichier. Par défaut ce sont les fichiers du même dossier ayant un atime proche.
Ensuite il exprime des exigences, notamment le nombre maximal de fragments, le nombre maximal de "miettes" (minuscules fragments qui font faire des déplacements consécutifs à la tête de lecture), et la distance vis à vis des amis (utile pour des programmes comme dpkg, make ou portage qui manipulent de nombreux fichiers d'un même dossier).
Ces exigences sont exprimées sous formes de seuils que les statistiques du fichier ne doivent pas dépasser.
Après cela, il examine la taille des fichiers et les classe en trois catégories : ceux qui sont petits et qui correspondent surtout à une fragmentation de l'espace libre (typiquement un fichier de configuration), ceux qui sont énormes (typiquement un film), et les autres.
À chacune de ces catégories il associe une tolérance, qui multiplie les seuils.
Enfin, il prends sa décision.
Il a également d'autres stratégies, par exemple éviter que des fichiers restent trop longtemps au même endroit en ré-allouant l'espace des vieux fichiers.
Il propose aussi un mode "lecture seule" (--pretend) dans lequel il ne fait qu'afficher des statistiques. Utilisé conjointement avec le module python pré-alpha qui extrait les informations de la sortie standard, il permettras à terme de faire une interface graphique plus classique, ou des statistiques détaillés sur la fragmentation.
Pour conclure, voici quelques exemples, extraits de la manpage :
Voir la fragmentation d'un dossier : shake --pretend --verbose --verbose DOSSIER
Examiner tous les MP3 des sous-dossiers, en conseillant de placer à coté ceux qui sont proches dans l'ordre lexical : find -type f -iname '*.mp3' | sort | shake
Aller plus loin
- La page du projet (1061 clics)
- Expériences d'utilisateurs sur les forums Gentoo (120 clics)
- Pourquoi Linux n'a pas besoin de défragmentation (400 clics)
# Re: Pourquoi Linux n'a pas besoin de défragmentation
Posté par un_brice (site web personnel) . Évalué à 10.
De mon point de vue, cet article est dans le vrai : dans la quasi-totalité des cas le système de fichier sait se débrouiller tout seul.
ShaKe vise précisement à déceler les seuls cas où le système de fichier échoue.
Il y en a au moins trois :
Premièrement, le cas où le disque est trop plein. Lors de la présentation à mes profs (à la base c'est un projet d'étude à Lyon1), j'avais fourni une image de filesystem qui faisait bien ressortir le problème : http://vleu.net/shake/disk.bin.bz2 . Sur cet exemple (très articiel), les fichiers "gros" (un méga si je me rappelle bien) passaient d'un millier de fragments à quelques uns. Le cas de cet utilisateur montre que ça arrive aussi dans la vraie vie http://forums.gentoo.org/viewtopic-t-463204-postdays-0-posto(...) .
Ensuite, les "fichiers sparses". Quand un programe Linux accède par exemple au 60ème méga octet d'un d'un fichier qui n'en fait que 5, le système de fichier ne génére pas un fichier plein de zeros pour "remplir le trou" mais "saute par dessus". On a alors systèmatiquement deux fragments. C'est une fonctionalité très interessante puisqu'elle fait gagner une quantitée non négligeable d'espace disque. Mais les logiciels de peer to peer (notament) lui causent problèmes car il reçoivent les morceaux dans un ordre plus ou moins aléatoire, ce qui cause de nombreux sauts et une fragmentation importante. Shake détecte ces sauts injustifiés, mais aussi ajoute des sauts dans le cas où il seraient utiles.
Enfin, il y a le problème de l'évolution de la taille et de l'usage des fichiers. ReiserFS (extN aussi je suppose) semble s'arranger pour placer les fichiers d'un même dossier ensemble, et dans l'ordre d'écriture. Mais aussi intelligent soit-il, le système ne peut pas anticiper deux ans d'utilisation, et si par exemple un dossier se voit ajouter une centaine de fichiers après être longtemps resté intact, ou si un fichier grossit sans cesse longtemps encore après avoir été crée, il seras bien obligé de fragmenter.
Il y a aussi d'autres choses, comme le fait que l'ordre d'écriture ne soit pas nécessairement l'ordre de lecture (shake réecrit les fichiers éloignés les un des autres dans l'ordre de lecture) et le fait que de nombreux fichiers restent "sur place" longtemps, fragmentant l'espace libre car le FS ne va pas de lui même les déplacer (shake les réecrit aussi).
Pour résumer : il y a des cas (rares) où les hypothèses que le système de fichier avait fait sur l'utilisateur, ou sur l'usage des fichiers sont fausses. Shake notifie le problème au système de fichier simplement en lui intimant l'ordre de les réecrire. L'efficacité du système de fichier sous jacent est donc justement ce qui fait marcher Shake et cet article va dans mon sens.
Par contre, s'il est donc suceptible d'être utile, ce n'est bel et bien pas au quotidien car ces cas sont rares.
# Réponse au 3° lien
Posté par Mjules (site web personnel) . Évalué à 2.
Why does Linux need defragmenting?
http://www.kdedevelopers.org/node/2270
En "rangeant" les fichiers, Shake semble répondre à sa problématique.
Tu devrais lui proposer ;)
[^] # Re: Réponse au 3° lien
Posté par mickabouille . Évalué à 7.
il compare le démarrage de kde depuis le disque au démarrage de kde depuis le cache!
Il a juste découvert que quand des données étaient en cache, on y accédait plus vite. C'est tout.
Après c'est vrai que c'est dû au seeks, mais aucun rapport avec la fragmentation puisque précisément, comme *il* l'explique, ce sont des seeks entre fichiers, pas entre fragments du même fichier.
Et le fait de positionner les fichiers lu l'un après l'autre pour accélérer la chose ne fonctionne que si le noyau gère ça (réordonnancement des opérations par le hardware plus souvent que par le noyau, parce qu'il se connait mieux que le noyau), et c'est encore en developpement.
[^] # Re: Réponse au 3° lien
Posté par Gof (site web personnel) . Évalué à 3.
Il précise que, considérant une vitesse de lecture des disques dur de 50Mo/s , et que le lancement de KDE ne devrais pas charger plus de 100Mo (mon cache ne fait même pas autant), il devrais y avoir une différence de 2 secondes entre démarrer avec ou sans cache.
Or, j'ai fait le test, j'observe une différence de 20 secondes, soit 10 fois plus.
C'est donc bien car les fichiers sont a des endroit différent du disque.
Maintenant, ShaKe va remettre les fichier des même dossiers à des endroit proche. Ça semble être la solution puisque bcp des fichiers lu au démarrage sont dans les même dossiers.
Ça me rappelle cette news sur "Accelerated Knoppix"
http://linuxfr.org/2006/03/03/20432.html
[^] # Re: Réponse au 3° lien
Posté par Antoine . Évalué à 4.
C'est un raisonnement sur un modèle idéal, mais en pratique d'autres facteurs vont dégrader les performances :
- la mise à jour de métadonnées (la date du dernier accès si tu n'as pas activé le drapeau noatime)
- d'autres événements peuvent avoir lieu en même temps (par exemple des ajouts dans un fichier log)
- pour atteindre ces vitesses maximales, le noyau doit être capable de mettre constamment en file d'attente les requêtes, par exemple en calculant du prefetching, ce qui n'est pas évident si les données à charger sont éparpillées sur une myriade de petits fichiers (comme le noyau peut-il prévoir qu'après /usr/lib/libkoko.so.2, c'est /usr/lib/libkarcher.so.4 qui doit être mise en file d'attente ?)
Sans compter qu'optimiser le temps de lancement de KDE ne sera pas forcément bénéfique pour d'autres cas d'usages (lancement de telle ou telle application) qui interviendront peut-être plus souvent en utilisation intensive.
[^] # Re: Réponse au 3° lien
Posté par Vador Dark (site web personnel) . Évalué à 1.
C'est justement ce qui est dit. Et justement, a priori, Shake devrait pouvoir réduire ce temps que l'on doit au morcellement en rapprochant les fichiers à charger.
[^] # Re: Réponse au 3° lien
Posté par Antoine . Évalué à 3.
Il y aura donc un intervalle de temps pendant lequel le disque dur ne fera rien et le débit maximal ne sera pas atteint.
[^] # Re: Réponse au 3° lien
Posté par mickabouille . Évalué à 2.
[^] # Re: Réponse au 3° lien
Posté par thedidouille . Évalué à 4.
Les libs, pour la plupart lors du lancement d'applications, ne sont pas ouverts et lus, mais elles sont mappées, donc l'accès sur le fichier est pseudo aléatoire ...
Il vaut mieux optimiser le placement des symboles et le layout des lib plutôt que de trafiquer le système de fichier AMHA.
[^] # Re: Réponse au 3° lien
Posté par THR4K . Évalué à 1.
Le comportement et les performances peuvent sensiblement varier en fonction de l'ordonnanceur utilisé (Noop, AS, Deadline ou CFQ voire ceux à base d'algos génétiques) et le type d'utilisation associé.
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
[^] # Re: Réponse au 3° lien
Posté par mickabouille . Évalué à 3.
Ce n'est pas le bon calcul, celui-ci se base sur le débit en séquentiel, alors qu'il faut le faire plutôt sur le temps d'accès. Quand est-ce que le débit pur d'un disque est utile? Quand tu fais une lecture d'un gros fichier, pas quand tu lis des fichiers de config.
Dans le cas de KDE, même si les fichiers sont physiquement proches, il ne va pas les lire à la suite les uns des autres. Lles autres tâches vont ajouter leurs propres accès à la file des opérations disques (réessaie le lancemen de kde, cette fois après avoir lancé une copie-pas deplacement, hein, copie- d'un fichier d'un Go entre deux emplacements sur un même disque dur). Peut ere même qu'elle en profitera pour écraser le cache disque par la même occasion...
[^] # Re: Réponse au 3° lien
Posté par mickabouille . Évalué à 6.
[^] # Re: Réponse au 3° lien
Posté par renoo . Évalué à 1.
Il pourrait aussi éviter la fragmentation pour les fichiers qui sont le plus utilisés (la fragmentation d'un fichier "mort" n'est pas importante). Tout cela, pourrait se faire de temps en temps automatiquement quand le cpu/disk ne fait rien.
[^] # Re: Réponse au 3° lien
Posté par pasBill pasGates . Évalué à 2.
Moi ironique ? Naaaaan....
# Exercice de style ?
Posté par Pierre Jarillon (site web personnel) . Évalué à -1.
Je pense donc que si l'utilité de ce programme est marginale, il s'agit néanmoins d'un bel exercice de style.
Il existe un défragmenteur humoristique que nous devons à Sébastien Blondeel :
--------------------------------------------------------------------------------------------
#!/bin/sh
echo "Defragmenting all hard drives"
for pourcent in `yes | head -100 | cat -n | sed 's/y//'`
do
echo "... $pourcent% completed"
sleep 5
done
echo "Now your system is nice and clean and ready to run faster!"
-- sbi (défragmenteur pour système de fichier ext2)
--------------------------------------------------------------------------------------------
et une variante issue d'une compétition spontanée sur la liste tech de l'ABUL :
--------------------------------------------------------------------------------------------
#!/bin/bash
for i in `seq 100`
do
echo $i
sleep 1
done | dialog --backtitle "Défragmenteur de disque universel (ext2/ext3, ReiserFS, XFS et JFS)" --title "defrag" --gauge "Défragmentation en cours ..." 18 60
dialog --backtitle "Défragmenteur de disque universel (ext2/ext3, ReiserFS et Vfat)" --title "defrag" --msgbox "Défragmentation terminée avec succès" 18 60
exit
--------------------------------------------------------------------------------------------
[^] # Re: Exercice de style ?
Posté par Antoine . Évalué à 7.
Cela n'a rien à avoir avec les virus. L'existence des virus se base sur l'existence de failles (conceptuelles ou d'implémentation) dans le modèle de sécurité. Ces failles sont observables de façon objective au moment de leur introduction.
Ici il ne s'agit pas de colmater des failles, de pallier au fait qu'il est impossible de prévoir l'avenir, et donc de savoir à l'avance quelle doit être l'organisation optimale du disque dur.
On sait bien que les systèmes de fichiers utilisés avec Linux font un boulot relativement correct pour éviter au maximum la fragmentation, mais on ne peut prétendre que la défragmentation est rigoureusement inutile.
Il serait intéressant, par exemple, de savoir l'impact que peut avoir l'utilitaire ici présenté sur les performances d'une base MySQL fréquemment modifiée (notamment avec des champs à taille variable type BLOB).
[^] # Re: Exercice de style ?
Posté par Matthieu . Évalué à 4.
[^] # Re: Exercice de style ?
Posté par Crao . Évalué à 6.
http://www.sabi.co.uk/Notes/anno05-4th.html#051226b
Dans d'autres articles du blog, il constate aussi que les performances se dégradent plus vite en ext3 qu'avec d'autres systèmes de fichier.
# ^-^
Posté par Anonyme . Évalué à 2.
Pour moi, la fragmentation sous Linux existe, et n'est certainement pas négligeable. La différence de performances sur les disques durs est la première chose qui m'a frappé lorsque j'ai switché de Windows, il y a quelques années. Même avec son écriture différée et autres artifices (qui au passage m'a emmerdé je ne sais combien de fois lors d'une écriture sur clé USB), la gestion des disques sous Linux est moins performante que sous Windows.
Par exemple, copier un gros fichier (genre une iso) est non seulement plus lent sous Linux, mais en plus ça me fait tout ramer (le curseur de la souris saccade, les autres applications mettent 3 plombes à réagir, et ne parlons pas d'ouvrir un programme à ce moment là !), et j'ai pu vérifier cela avec différentes distributions (Mandriva, Debian, Ubuntu, etc.).
Le problème est bien présent, et les personnes qui l'éludent en prétextant qu'il n'existe pas n'ont soit pas utilisé Windows depuis des années, soit font preuve d'une certaine dose de mauvaise foi.
Cela dit, je ne suis pas certain que la fragmentation soit la raison du problème de différence de performances dans la gestion des disques. Certes, cela doit jouer un peu, mais à mon avis, le noyau est le principal responsable.
[^] # Re: ^-^
Posté par Thibault . Évalué à 4.
[^] # Re: ^-^
Posté par Anonyme . Évalué à 8.
[^] # Re: ^-^
Posté par Gniarf . Évalué à 4.
[^] # Re: ^-^
Posté par Pinaraf . Évalué à 5.
Ça c'est fréquent quand le DMA n'est pas activé. T'as quoi comme chipset ?
Pour ma part, j'ai jamais vu de tels problèmes sur mes machines, par contre je l'ai déjà vu sur la machine de quelqu'un d'autre où la carte mère était en train de mourir... (et sous windows ça merdait tout autant)
[^] # Re: ^-^
Posté par Anonyme . Évalué à 4.
La carte mère est une Asus A7N8X, chipset NForce2, et à l'époque où j'avais encore Windows en dual boot, aucun problème sous Windows.
$ dmesg|grep DMA
NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: 241254720 sectors (123522 MB) w/1821KiB Cache, CHS=16383/255/63, UDMA(100)
hdb: 241254720 sectors (123522 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100)
hdc: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(133)
hdd: ATAPI 63X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(33)
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
[^] # Re: ^-^
Posté par djibb (site web personnel) . Évalué à 3.
/dev/hda:
Timing cached reads: 1072 MB in 2.01 seconds = 534.23 MB/sec
Timing buffered disk reads: 70 MB in 3.16 seconds = 22.14 MB/sec
et "hdparm /dev/hda"
/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 78140160, start = 0
et toi ?
NB : les débits ne sont pas fantastiques car la puce gérant l'ide est juste une ide66
[^] # Re: ^-^
Posté par Anonyme . Évalué à 2.
/dev/hda:
Timing cached reads: 1204 MB in 2.00 seconds = 601.08 MB/sec
Timing buffered disk reads: 112 MB in 3.06 seconds = 36.65 MB/sec
# hdparm /dev/hda
/dev/hda:
multcount = 0 (off)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 241254720, start = 0
# hdparm -tT /dev/hdb
/dev/hdb:
Timing cached reads: 1332 MB in 2.00 seconds = 666.14 MB/sec
Timing buffered disk reads: 134 MB in 3.02 seconds = 44.40 MB/sec
# hdparm /dev/hdb
/dev/hdb:
multcount = 0 (off)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 241254720, start = 0
bon, hdc est sensiblement dans les mêmes eaux. (Évidemment le problème, c'est hda, qui carbure à du 5 Mo/s en transfert de gros fichiers au mieux, alors que hdb et hdc tournent à 20~30 Mo/s)
[^] # Re: ^-^
Posté par un_brice (site web personnel) . Évalué à 2.
Si t'a le temps, essaie donc shake --no-xattr --new=0 /. Si ça marche mal (y'a du tweaking à faire sur certaines constantes...), essaie de m'envoyer le shake -pvv d'un gros fichier.
Et vérifie que t'a pas une partition ReiserFS3 montée sans notail, c'est le piège.
Du reste, je suis de bonne foi et les ralentissements dont tu parle ne m'affectent pas. Essaie d'autres système des fichiers et ordonanceurs (j'ai Reiser3 sans notail et avec atime, l'anticipatory scheduler). Le problème ne peut venir que de là.
[^] # Re: ^-^
Posté par Crao . Évalué à 2.
[^] # Re: ^-^
Posté par benoar . Évalué à 4.
Je te conseille un petit oprofile quand ton système rame, pour savoir d'où ça vient :
oprofile --init
oprofile --setup --vmlinux=/boot/vmlinux
oprofile --reset
oprofile --start
[lancer la copie, attendre un peu ...]
oprofile --stop
Puis un petit opreport -l après, et regarde ce qui vient en haut. Enlève le '-l' pour avoir le classement par appli. Chez moi il passait plein de temps à faire du malloc() et d'autres joyeusetés (à quoi ça sert d'utiliser un buffer constant pour la copie, alors qu'on peut s'amuser à le redimensionner à chaque fois \o/ ...)
[^] # Re: ^-^
Posté par Anonyme . Évalué à 2.
[^] # Re: ^-^
Posté par gpe . Évalué à 2.
La seule fois ou j'ai eu ce genre de problème c'était avec une knoppix où le dma n'était pas activé.
[^] # Re: ^-^
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: ^-^
Posté par Anonyme . Évalué à 2.
[^] # Re: ^-^
Posté par Christophe Chailloleau-Leclerc . Évalué à 8.
[^] # Re: ^-^
Posté par Nikoo . Évalué à 5.
je trouve justement que sous Linux, les transferts de gros dossiers (plusieurs gigas) font moins ralentir le système que sous Windows (sans parler du fait que les fenêtres de transfert peuvent etre réduite sous linux, et pas sous windows...).
Par ailleurs, même lancer des transferts depuis des zones différentes du disque vers 2 localités différentes (un autre disque interne et un disque externe) est également "mieux" réalisé sous linux, le reste du système répondant toujours assez bien (alors que sous windows, ça rame vraiment à fond).
Je suis sous Kubuntu Dapper avec des partitions XFS (précedemment Mandriva, ReiserFS).
[^] # Re: ^-^
Posté par Jean-Philippe (site web personnel) . Évalué à 4.
Les autres applicatiosn ne deviennent pas inutilisables mais dans une lecture de video par exemple, il y a un lag certain.
[^] # Re: ^-^
Posté par Guillaume Knispel . Évalué à 3.
Par contre ça me ralenti enormement le lancement des programmes, ce qui est normal (enfin en théorie ça pourrait etre évité si le système pouvait distinguer entre un acces ponctuel avec necessité d'un temps de réponse bas, tel un chargement de programme / biblio, et un bulk transfert qui ne perd rien à être interrompu n'importe quand de manière temporaire).
[^] # Re: ^-^
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Et bien ça marche rudement bien, même les vidéos sauvées sur une partition chiffrée se lisent sans lag...
Seul bémol, l'écriture de gros fichier (copie/écriture) mette a genoux le processeur...
Et un téléchargement p2p type bittorrent avec 22iso a 256ko/s me bouffent environ 40-50% système et pratiquement autant en utilisateur...
(athlon 3200+ 512k)
Plus sérieusement les copies de (gros) fichiers on toujours tendance a mettre a genoux le processeur...
Mais sur de l'ide les performances sont maximisées quand les disques sont seul sur un contrôleur ide...
(même avec des cartes extensions ide bas de gamme on gagne en performance...)
Après certaines architectures sont meilleures que d'autre, les nforce en dual channel donne de meilleur résultat chez moi au niveau réactivité
(enfin c'est une forte impression)
[^] # Re: ^-^
Posté par kunta . Évalué à 4.
<\hs Sinon Nikoo XFS t'apporte quoi de plus par rapport a reiser4 ou ext3 \hs>
[^] # Re: ^-^
Posté par Nikoo . Évalué à 1.
Ben, je ne sais pas trop en fait :p.
Il me semble avoir lu quelque part que XFS était plus rapide, et comme j'avais décidé de passer de Mandriva à Kubuntu, j'ai en même temps décidé de reformater mes partitions dans ce format pour essayer.
Donc avec la même charge de disques, mon système m'a l'air plus rapide et semble mieux répondre.
Mais, et c'est un gros mais, comme je suis en même temps passé à Kubuntu, j'ignore si finalement ce n'est pas la distribution qui possède ces plus.
Donc en gros, je ne sais pas ce que ce passage XFS>ReiserFS m'a apporté.
:p
P.S. on se moque pas, merci ;-)
\hs>
[^] # Re: ^-^
Posté par Guillaume_T . Évalué à 3.
Perso, j'avais essayé, je suis revenu à ext3 : marre de perdre des dizaines de fichiers modifiés à chaque plantage, mon PC n'étant pas un modèle de stabilité
[^] # Re: ^-^
Posté par alnicodon . Évalué à 2.
Donc, la fois d'après, j'ai fait avec un disque dur externe, et pour rapatrier vers mon ordi principal, échaudé par la dernière fois, je m'armais de mon md5sum.
Dans un terminal, je fais cp --verbose *.iso /dest/
dans l'autre, je fais md5sum *.iso
Et alors ?
Alors, c'est trop fort: le md5sum m'affiche le checksum d'un fichier au moment même au cp --verbose m'annonce qu'il attaque la copie du suivant.
Les caches font quand même des merveilles: je fais deux traitement sur mes données pour le prix d'un accès disque. C'était ma petite soirée contemplative
Al.
[^] # Re: ^-^
Posté par Croconux . Évalué à 6.
[^] # Re: ^-^
Posté par Guillaume D. . Évalué à 4.
[^] # Re: ^-^
Posté par Sufflope (site web personnel) . Évalué à 2.
[^] # Re: ^-^
Posté par berti . Évalué à 1.
[^] # Re: ^-^
Posté par un_brice (site web personnel) . Évalué à 2.
[^] # Re: ^-^
Posté par mats . Évalué à 2.
C'est la plupart du temps lui qui s'accapare toutes les ressources.
Si vous avez le temps (rare) et des utilisateurs capables de faire planter excell en réseau (très courant), essayez d'effacer en utilisant l'explorateur les fichiers dump générés par cet excellent tableur si professionnel. Bon courage !!!
Un simple clic droit sur le fichier (qui peut faire 5-6Go) le charge en mémoire. À moins de posséder 10Go de mémoire sur le serveur win2003, bin y en a pour la matinée avant d'avoir le menu contextuel.
[^] # Re: ^-^
Posté par lolop (site web personnel) . Évalué à 5.
Même problème sous Windows, qui a aussi des systèmes de cache: il faut s'assurer que le cache est bien vidé avant de déconnecter la clée.
Sous Windows il y a "retirer le périphérique en toute tranquilité/sécurité"
Sous KDE, il y a qq chose d'équivalent (et ça doit sûrement se trouver sous Gnome) qui permet de démonter un volume amovible avant de le déconnecter.
Parce que - expérience personnelle - ça m'est arrivé de faire sous Windows une copie de nombreux fichiers d'un HD vers une clé USB, d'attendre que la fenêtre de copie soit refermée, puis de retirer la clé immédiatement. Hé ben j'ai foiré -et bien foiré- la table d'allocation FAT de la clé.
Depuis je passe systématiquement par les outils de démontage "en toute sécurité".
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: ^-^
Posté par NeoX . Évalué à 2.
et si la fonction existe ce n'est surement pas pour rien.
je confirme que sous gnome il y a aussi un menu pour "demonter"/"ejecter" le peripherique amovible avant de le debrancher.
[^] # Re: ^-^
Posté par littletux . Évalué à 2.
Des collègues, qui regardaient la fenêtre au lieu de la diode du lecteur ont niqué des boites entières de disquettes comme ça !!!
[^] # Re: ^-^
Posté par lolop (site web personnel) . Évalué à 2.
Des disquettes, des disquettes... ah oui, ces petits bouts de plastiques plats et fragiles avec un disque souple à l'intérieur :-)
J'en ai encore un lecteur sur ma machine au boulot... mais chez moi ils sont démontés (finalement je passe par une clé USB, même Linux sait la gérer). Le seul moment où j'en aurais vraiment besoin... c'est pour flasher le BIOS de la carte mère - ça semble le seul moyen supporté par certains fabriquants: du (free)DOS + une appli à eux qui tappe directement dans le matériel.
Et c'est toute une galère pour trouver un support...
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# en cours d'utilisation
Posté par fabien . Évalué à 2.
il est ecrit sur le site que le FS peu être defragmenter en cours d'utilisation.
que ce passe t'il si shake defrag un gros fichier et qu'une application souhaite y acceder en lecture ? en ecriture?.. par exemple les données d'une base de données ?...
[^] # Re: en cours d'utilisation
Posté par un_brice (site web personnel) . Évalué à 5.
/* Put the lock */
if (l->locks && -1 == flock (a->fd, LOCK_EX | LOCK_NB))
{
error (0, errno, "%s: failed to acquire a lock", a->name);
goto freeall;
}).
Le problème ne peut donc se poser qu'avec les applications qui n'honorent pas les verrous. Le seul moyen de s'en prémunir serait d'activer le "Mandatory Lock", qui force les applications à respecter le verrous (documenté dans /usr/src/linux/Documentation/mandatory.txt ), mais de mon point de vue c'est un hack et je ne l'activerais que si c'est vraiment nécessaire.
Il y a trois autres sécurité pour éviter les problèmes de corruption :
La fonction capture (struct accused *a, struct law *l), à la ligne 177 de executive.c qui est appellée avant les opérations d'écriture masque les signaux (notement).
Après une opération de défragmentation, il vérifie rapidement que rien ne manque.
À tout moment, une copie du fichier en cours d'écriture est disponible. Si ShaKe échoue (par exemple à allouer la mémoire) il indique son emplacement puis se suicide.
[^] # Re: en cours d'utilisation
Posté par Antoine . Évalué à 5.
Je crains que la majorité des applications ne prennent pas la peine de poser un verrou.
Les seuls cas où un programmeur posera un verrou, ce sera quand il voudra interdire les accès concurrents depuis plusieurs instances de son appli, pas pour éviter qu'un utilitaire annexe dont il ne soupçonne pas l'existence (type défragmenteur) ne foute tout en l'air.
[^] # Re: en cours d'utilisation
Posté par un_brice (site web personnel) . Évalué à 2.
Je vais rapidement sortir une 0.25 pour me mettre en conformité avec Savannah, mais la 0.26 auras cette fonctionalité (probablement activée par défaut).
# Et sur du RAID
Posté par Maz (site web personnel) . Évalué à 3.
Y'a-t-il un intérêt de cet outil sur des partitions RAID (software), que ce soit 0,1 ou 5. Ou au contraire, cela risque de poser plus de problèmes qu'autre chose ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.