Fichier perdu suite à manque de place sur le dd (pas de TM)
34 réponses
Une Bévue
Un ami qui n'utilise pas TM a perdu un fichier suite à manque de place
sur son disque, RapidWeaver râle à l'enregistrement, depuis cette
personne ne retrouve plus son fichier qu'il avait pourtant déjà
enregistré à moulte reprises.
Qqc à faire ?
Perso je pense que son travail est irrémédiablement perdu...
C'est un peu difficile a imaginer, mais si le disque est vraiment saturé a ce point, le système va rapidement avoir du mal a fonctionner correctement et il ne faut plus se servir de cet ordi tant que plusieurs Go ne seront pas libéré.
Heu ca parait obsolete non ?
Pourquoi ?
Parce que sous pretexte que l'utilisateur copie un fichier qui sature complement le disque, ca me parait bizarre que cela nuise au bon fonctionnement du systeme. Autant je comprendrais que si le disque est saturé l'utilisateur ne peut plus copier/créer de nouveau fichier mais remettre tout le système parce qu'un utilisateur sature le disque parait être un comportement qui ne devrait plus exister au jour d'aujourd hui
D'un autre côté ça a l'avantage de ne pas à avoir à décider à priori quelle taille maximum allouer au swap.
Ca a des avantages et des inconvénients.
Le 22/04/2014 19:31, william a écrit :
On 2014-04-22, Pierre-Alain Dorange <pdorange@pas-de-pub-merci.mac.com> wrote:
william <blop@no.spam> wrote:
C'est un peu difficile a imaginer, mais si le disque est vraiment saturé
a ce point, le système va rapidement avoir du mal a fonctionner
correctement et il ne faut plus se servir de cet ordi tant que plusieurs
Go ne seront pas libéré.
Heu ca parait obsolete non ?
Pourquoi ?
Parce que sous pretexte que l'utilisateur copie un fichier qui sature
complement le disque, ca me parait bizarre que cela nuise au bon fonctionnement
du systeme. Autant je comprendrais que si le disque est saturé l'utilisateur ne
peut plus copier/créer de nouveau fichier mais remettre tout le système parce
qu'un utilisateur sature le disque parait être un comportement qui ne devrait
plus exister au jour d'aujourd hui
D'un autre côté ça a l'avantage de ne pas à avoir à décider à priori
quelle taille maximum allouer au swap.
C'est un peu difficile a imaginer, mais si le disque est vraiment saturé a ce point, le système va rapidement avoir du mal a fonctionner correctement et il ne faut plus se servir de cet ordi tant que plusieurs Go ne seront pas libéré.
Heu ca parait obsolete non ?
Pourquoi ?
Parce que sous pretexte que l'utilisateur copie un fichier qui sature complement le disque, ca me parait bizarre que cela nuise au bon fonctionnement du systeme. Autant je comprendrais que si le disque est saturé l'utilisateur ne peut plus copier/créer de nouveau fichier mais remettre tout le système parce qu'un utilisateur sature le disque parait être un comportement qui ne devrait plus exister au jour d'aujourd hui
D'un autre côté ça a l'avantage de ne pas à avoir à décider à priori quelle taille maximum allouer au swap.
Ca a des avantages et des inconvénients.
pdorange
pehache wrote:
>> D'accord mais de là à alerter à 50 Go... > > 96% du disque occupé, c'est beaucoup. > Même si cela laisse 50 Go de libre, ça doit être par petits paquets un > peu partout et surtout ça laisse peu de marge de man½uvre au système > pour défragmenter ou gérer les caches et autres mémoire virtuelle...
Si on attend d'être à 95% d'occupation avant de défragmenter, en effet ça peut poser problème. MAis justement OS X défragmente plus ou moins en continu.
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
pehache <pehache.7@gmail.com> wrote:
>> D'accord mais de là à alerter à 50 Go...
>
> 96% du disque occupé, c'est beaucoup.
> Même si cela laisse 50 Go de libre, ça doit être par petits paquets un
> peu partout et surtout ça laisse peu de marge de man½uvre au système
> pour défragmenter ou gérer les caches et autres mémoire virtuelle...
Si on attend d'être à 95% d'occupation avant de défragmenter, en effet
ça peut poser problème. MAis justement OS X défragmente plus ou moins en
continu.
>> D'accord mais de là à alerter à 50 Go... > > 96% du disque occupé, c'est beaucoup. > Même si cela laisse 50 Go de libre, ça doit être par petits paquets un > peu partout et surtout ça laisse peu de marge de man½uvre au système > pour défragmenter ou gérer les caches et autres mémoire virtuelle...
Si on attend d'être à 95% d'occupation avant de défragmenter, en effet ça peut poser problème. MAis justement OS X défragmente plus ou moins en continu.
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
pdorange
william wrote:
>> Heu ca parait obsolete non ? > Pourquoi ?
Parce que sous pretexte que l'utilisateur copie un fichier qui sature complement le disque, ca me parait bizarre que cela nuise au bon fonctionnement du systeme.
C'est à dire que quand le diqeu est plein... il est plein pour tout le monde. L'OS ayant besoin de créer des fichiers en permanence (pleins de petits pas forcéement fondamentaux mais d'autres plus importants, notamment les swap).
Autant je comprendrais que si le disque est saturé l'utilisateur ne peut plus copier/créer de nouveau fichier mais remettre tout le système parce qu'un utilisateur sature le disque parait être un comportement qui ne devrait plus exister au jour d'aujourd hui
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
william <blop@no.spam> wrote:
>> Heu ca parait obsolete non ?
> Pourquoi ?
Parce que sous pretexte que l'utilisateur copie un fichier qui sature
complement le disque, ca me parait bizarre que cela nuise au bon
fonctionnement du systeme.
C'est à dire que quand le diqeu est plein... il est plein pour tout le
monde.
L'OS ayant besoin de créer des fichiers en permanence (pleins de petits
pas forcéement fondamentaux mais d'autres plus importants, notamment les
swap).
Autant je comprendrais que si le disque est saturé l'utilisateur ne peut
plus copier/créer de nouveau fichier mais remettre tout le système parce
qu'un utilisateur sature le disque parait être un comportement qui ne
devrait plus exister au jour d'aujourd hui
Parce que sous pretexte que l'utilisateur copie un fichier qui sature complement le disque, ca me parait bizarre que cela nuise au bon fonctionnement du systeme.
C'est à dire que quand le diqeu est plein... il est plein pour tout le monde. L'OS ayant besoin de créer des fichiers en permanence (pleins de petits pas forcéement fondamentaux mais d'autres plus importants, notamment les swap).
Autant je comprendrais que si le disque est saturé l'utilisateur ne peut plus copier/créer de nouveau fichier mais remettre tout le système parce qu'un utilisateur sature le disque parait être un comportement qui ne devrait plus exister au jour d'aujourd hui
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
truc
oeuf corseJ.P. Kuypers wrote:
In article (Dans l'article) <1lkg47i.mu7slz19hft8gN%, B. Graignic wrote (écrivait) :
> il me reste 50 Go sur 1To, et ça monte rapidement.
La Corbeille est-elle vidée ?
oeuf corse
je me demandais si les mise à jour tant du système que des applications ne chargeaient pas des fichiers pour faire, justement, ces mises à jour sans les détruire après.
In article (Dans l'article) <1lkg47i.mu7slz19hft8gN%truc@machin.com>,
B. Graignic <truc@machin.com> wrote (écrivait) :
> il me reste 50 Go sur 1To, et ça monte rapidement.
La Corbeille est-elle vidée ?
oeuf corse
je me demandais si les mise à jour tant du système que des applications
ne chargeaient pas des fichiers pour faire, justement, ces mises à jour
sans les détruire après.
--
B. Graignic
enlever-bgraig@wanadoo.fr
http://pagesperso-orange.fr/fontguyon.antignac/
In article (Dans l'article) <1lkg47i.mu7slz19hft8gN%, B. Graignic wrote (écrivait) :
> il me reste 50 Go sur 1To, et ça monte rapidement.
La Corbeille est-elle vidée ?
oeuf corse
je me demandais si les mise à jour tant du système que des applications ne chargeaient pas des fichiers pour faire, justement, ces mises à jour sans les détruire après.
