j'ai un petit soucis. Mon disque est partitionné et est plein a ras de
la gueule.
J'ai voulu redimentionner, mais ca marche pas car c'est Ext3 et y a
pas de place avant ni apres.
Et je me vois pas faire un backup de 200Go sur DVD.
Bon les donnees sont pas vitale mais bon je prendrai bien le risque
sans convertir si c'est possible.
Quelqu'un peut m'expliquer pourquoi c'est si difficile avec ext3 ?
MErci
--
Probleme non resolu sous linux:
1) mettre un quota sur les poubelles pour eviter la saturation des disques (comme sous windows)
2) est il possible de compresser des repertoires ou fichier pour qu'il prennent moins de place en ext3 ? (comme sous NTFS)
3) Comment faire le menage dans / car c'est le bordel. Peut on modifier sans probleme la hierarchie pour n'avoir que /system, /home ?
4) Comment au demarrage faire une ouverture de session en mode verouillé et caché ?
Oui, j'avais vu... Mais, resize2fs ne joue que sur le filesysteme, apres faut retailler la partition. Je ne sais pas comment les outils graphiques gerent ca...
Alors si tu veux jouer avec tes partitions, ton filesystem etc, je ne peux que te conseiller LVM + xfs
Euh pour XFS tu peux le réduire ?
jamais essayé. Je sais que xfs accepte de grossir, d'ou le LVM pour avoir un disque aussi gros que l'on souhaite, virtuellement illimité.
On 17 avr, 17:44, Philippe WEILL <Philippe.We...@aero.jussieu.fr>
wrote:
Oui, j'avais vu...
Mais, resize2fs ne joue que sur le filesysteme, apres faut retailler la
partition. Je ne sais pas comment les outils graphiques gerent ca...
Alors si tu veux jouer avec tes partitions, ton filesystem etc, je
ne peux que te conseiller
LVM + xfs
Euh pour XFS tu peux le réduire ?
jamais essayé. Je sais que xfs accepte de grossir, d'ou le LVM pour
avoir un disque
aussi gros que l'on souhaite, virtuellement illimité.
Oui, j'avais vu... Mais, resize2fs ne joue que sur le filesysteme, apres faut retailler la partition. Je ne sais pas comment les outils graphiques gerent ca...
Alors si tu veux jouer avec tes partitions, ton filesystem etc, je ne peux que te conseiller LVM + xfs
Euh pour XFS tu peux le réduire ?
jamais essayé. Je sais que xfs accepte de grossir, d'ou le LVM pour avoir un disque aussi gros que l'on souhaite, virtuellement illimité.
Nicolas George
wrote in message :
deuxieme ordre, tu as upx http://upx.sourceforge.net/ qui marche plutot pas mal.
Attention, ça supprimer le partage en mémoire. Donc on économise un peu de disque dur, et un tout petit peu de temps de chargement, mais on perd considérablement en occupation mémoire (et donc en cache disque, donc un reperd ce qu'on a gagné en temps de chargement).
octane@alinto.com wrote in message
<1176886926.387008.245850@q75g2000hsh.googlegroups.com>:
deuxieme ordre, tu as upx http://upx.sourceforge.net/ qui marche
plutot pas mal.
Attention, ça supprimer le partage en mémoire. Donc on économise un peu de
disque dur, et un tout petit peu de temps de chargement, mais on perd
considérablement en occupation mémoire (et donc en cache disque, donc un
reperd ce qu'on a gagné en temps de chargement).
deuxieme ordre, tu as upx http://upx.sourceforge.net/ qui marche plutot pas mal.
Attention, ça supprimer le partage en mémoire. Donc on économise un peu de disque dur, et un tout petit peu de temps de chargement, mais on perd considérablement en occupation mémoire (et donc en cache disque, donc un reperd ce qu'on a gagné en temps de chargement).
octane
On 18 avr, 11:04, Eric Belhomme <{rico}+no/ wrote:
Les gros systeme de base de donnee ne compresse pas ?
Jamais essayé. Effectivement ca pourrait sembler interessant.
Certainement pas des bases actives !!! les gros SGBDR préconisent des grosses partitions, de préférence en RAID0 ou RAID10 pour les perform ances, et de séparer les bases de jouneaux de transactions sur des disques physiquement distincts, toujours pour des raisons de performance...
J'ai meme vu que postgreSQL sait utiliser des partitions directement,
sans filesystem pour accelerer les choses.
Le but 1er d'un SGBDR, ce n'est pas d'être léger en espace disque con sommé, mais d'être *rapide*
Mais paradoxalement la compression peut permettre de gagner en
rapidite, modulo le cout CPU. Un exemple, j'ai un disque qui lit a 1Mo/s. J'ai un fichier qui fait 100Mo rempli de zeros. Je vais mettre 100secondes à le lire dans le meilleur des cas, en tenant compte que le disque n'est pas sollicité par ailleurs. Si le filesystem est compressé, le fichier comprimé fera 10k. La lecture sera immédiate et le CPU pourra envoyer le fichier de 100Mo a la vitesse du bus a qui c'est destine (carte reseau, memoire, etc). Donc la compression du filesystem accelere le temps d'acces. Dans d'autre cas, le gain de la compression sera nulle (exemple d'un mp3) et fera inutilement travailler le CPU, Ok.Je suppose qu'a l'extreme on peut trouver des exemples ou la compression du fs ne fera que ralentir l'acces aux donnees. Mais avec une certaine politique, cela peut etre benefique.
Ceci "pourrait" s'appliquer a un SGBD. (je met des guillemets) On peut imaginer que dans certains cas, la compression va accelerer l'envoi des donnees. Existe t'il des politiques de compression de donnees au niveau du SGBD directement? Y'a t'il eu des benchs de fait la dessus? Ou est le goulet d'etranglement d'un SGBD? CPU ou acces disque?
En revanche, une fois déconectée, une base se compresse bien. heureus ement pour les backups !
Les rares fois ou j'ai utilise des SGBD je n'avais que du texte. Donc
la sortie d'un pgdump se comprimait effectivement tres bien :-)
On 18 avr, 11:04, Eric Belhomme <{rico}+no/s...@ricospirit.net> wrote:
Les gros systeme de base de donnee ne compresse pas ?
Jamais essayé. Effectivement ca pourrait sembler interessant.
Certainement pas des bases actives !!! les gros SGBDR préconisent des
grosses partitions, de préférence en RAID0 ou RAID10 pour les perform ances,
et de séparer les bases de jouneaux de transactions sur des disques
physiquement distincts, toujours pour des raisons de performance...
J'ai meme vu que postgreSQL sait utiliser des partitions directement,
sans
filesystem pour accelerer les choses.
Le but 1er d'un SGBDR, ce n'est pas d'être léger en espace disque con sommé,
mais d'être *rapide*
Mais paradoxalement la compression peut permettre de gagner en
rapidite,
modulo le cout CPU.
Un exemple, j'ai un disque qui lit a 1Mo/s. J'ai un fichier qui fait
100Mo
rempli de zeros. Je vais mettre 100secondes à le lire dans le meilleur
des
cas, en tenant compte que le disque n'est pas sollicité par ailleurs.
Si le filesystem est compressé, le fichier comprimé fera 10k. La
lecture sera
immédiate et le CPU pourra envoyer le fichier de 100Mo a la vitesse
du
bus a qui c'est destine (carte reseau, memoire, etc). Donc la
compression
du filesystem accelere le temps d'acces.
Dans d'autre cas, le gain de la compression sera nulle (exemple d'un
mp3)
et fera inutilement travailler le CPU, Ok.Je suppose qu'a l'extreme on
peut trouver des exemples ou la compression du fs ne fera que ralentir
l'acces aux donnees. Mais avec une certaine politique, cela peut
etre benefique.
Ceci "pourrait" s'appliquer a un SGBD. (je met des guillemets)
On peut imaginer que dans certains cas, la compression va accelerer
l'envoi des donnees. Existe t'il des politiques de compression de
donnees
au niveau du SGBD directement? Y'a t'il eu des benchs de fait la
dessus? Ou est le goulet d'etranglement d'un SGBD? CPU ou acces
disque?
En revanche, une fois déconectée, une base se compresse bien. heureus ement
pour les backups !
Les rares fois ou j'ai utilise des SGBD je n'avais que du texte. Donc
la sortie
d'un pgdump se comprimait effectivement tres bien :-)
On 18 avr, 11:04, Eric Belhomme <{rico}+no/ wrote:
Les gros systeme de base de donnee ne compresse pas ?
Jamais essayé. Effectivement ca pourrait sembler interessant.
Certainement pas des bases actives !!! les gros SGBDR préconisent des grosses partitions, de préférence en RAID0 ou RAID10 pour les perform ances, et de séparer les bases de jouneaux de transactions sur des disques physiquement distincts, toujours pour des raisons de performance...
J'ai meme vu que postgreSQL sait utiliser des partitions directement,
sans filesystem pour accelerer les choses.
Le but 1er d'un SGBDR, ce n'est pas d'être léger en espace disque con sommé, mais d'être *rapide*
Mais paradoxalement la compression peut permettre de gagner en
rapidite, modulo le cout CPU. Un exemple, j'ai un disque qui lit a 1Mo/s. J'ai un fichier qui fait 100Mo rempli de zeros. Je vais mettre 100secondes à le lire dans le meilleur des cas, en tenant compte que le disque n'est pas sollicité par ailleurs. Si le filesystem est compressé, le fichier comprimé fera 10k. La lecture sera immédiate et le CPU pourra envoyer le fichier de 100Mo a la vitesse du bus a qui c'est destine (carte reseau, memoire, etc). Donc la compression du filesystem accelere le temps d'acces. Dans d'autre cas, le gain de la compression sera nulle (exemple d'un mp3) et fera inutilement travailler le CPU, Ok.Je suppose qu'a l'extreme on peut trouver des exemples ou la compression du fs ne fera que ralentir l'acces aux donnees. Mais avec une certaine politique, cela peut etre benefique.
Ceci "pourrait" s'appliquer a un SGBD. (je met des guillemets) On peut imaginer que dans certains cas, la compression va accelerer l'envoi des donnees. Existe t'il des politiques de compression de donnees au niveau du SGBD directement? Y'a t'il eu des benchs de fait la dessus? Ou est le goulet d'etranglement d'un SGBD? CPU ou acces disque?
En revanche, une fois déconectée, une base se compresse bien. heureus ement pour les backups !
Les rares fois ou j'ai utilise des SGBD je n'avais que du texte. Donc
la sortie d'un pgdump se comprimait effectivement tres bien :-)
Nicolas George
wrote in message :
Ceci "pourrait" s'appliquer a un SGBD.
Il y a peu de chance : la compression s'applique bien quand il y a des gros blocs de données avec beaucoup de redondance. Ton fichier de 100 Mo de 0 se comprime bien, mais si tu prends seulement une vingtaine d'octets, ça ne va plus marcher du tout. Il y a quelques algorithmes de compression qui vont savoir travailler sur des petits blocs individuellement, mais ce ne sont pas les meilleurs. La plupart du temps, pour savoir ce que vaut un octet au milieu d'un fichier comprimé, il faut décomprimer tout depuis le début.
Or les bases de données, c'est essentiellement des accès aléatoires, par petits blocs, dans tous les sens. Donc la compression se révélera assez inefficace.
Pour cette même raison, la compression au niveau du filesystem n'est pas une bonne idée : le filesystem n'a pas assez d'information pour choisir les blocs de compression. Il vaut largement mieux que la compression se situe au niveau applicatif, où la logique de l'application sait comment découper les données pour avoir un bon résultat.
octane@alinto.com wrote in message
<1176888335.171935.88410@n76g2000hsh.googlegroups.com>:
Ceci "pourrait" s'appliquer a un SGBD.
Il y a peu de chance : la compression s'applique bien quand il y a des gros
blocs de données avec beaucoup de redondance. Ton fichier de 100 Mo de 0 se
comprime bien, mais si tu prends seulement une vingtaine d'octets, ça ne va
plus marcher du tout. Il y a quelques algorithmes de compression qui vont
savoir travailler sur des petits blocs individuellement, mais ce ne sont pas
les meilleurs. La plupart du temps, pour savoir ce que vaut un octet au
milieu d'un fichier comprimé, il faut décomprimer tout depuis le début.
Or les bases de données, c'est essentiellement des accès aléatoires, par
petits blocs, dans tous les sens. Donc la compression se révélera assez
inefficace.
Pour cette même raison, la compression au niveau du filesystem n'est pas une
bonne idée : le filesystem n'a pas assez d'information pour choisir les
blocs de compression. Il vaut largement mieux que la compression se situe au
niveau applicatif, où la logique de l'application sait comment découper les
données pour avoir un bon résultat.
Il y a peu de chance : la compression s'applique bien quand il y a des gros blocs de données avec beaucoup de redondance. Ton fichier de 100 Mo de 0 se comprime bien, mais si tu prends seulement une vingtaine d'octets, ça ne va plus marcher du tout. Il y a quelques algorithmes de compression qui vont savoir travailler sur des petits blocs individuellement, mais ce ne sont pas les meilleurs. La plupart du temps, pour savoir ce que vaut un octet au milieu d'un fichier comprimé, il faut décomprimer tout depuis le début.
Or les bases de données, c'est essentiellement des accès aléatoires, par petits blocs, dans tous les sens. Donc la compression se révélera assez inefficace.
Pour cette même raison, la compression au niveau du filesystem n'est pas une bonne idée : le filesystem n'a pas assez d'information pour choisir les blocs de compression. Il vaut largement mieux que la compression se situe au niveau applicatif, où la logique de l'application sait comment découper les données pour avoir un bon résultat.
Nicolas.MICHEL
Le chat de personne wrote:
Non ce que je veux dire c'est qu'on utilise des chemins de traverse alors que je ne trouve rien qui aille tout droit.
Pour que ça aille tout droit, il aurait fallu entrer par l'allée principale et ne pas t'engager d'emblée dans de petites ruelles.
Parce que déjà, tu as du multiboot et ça même sous windows c'est pas tout tracé d'avance, le MBR et tout ce merdier n'a rien de facile.
Ensuite tu as sauciçonné tes disques en de multiples partitions, sans utiliser lvm, c'est un bon moyen pour se pendre dans le tapis.
Sous NTFS, tu reduit la partition, tu cree une partition sur la place liberée, tu valide et c'est bon.
La seule fois que le l'ai fait, avec partition magic, ça a foiré, j'ai perdu mes données.
Sous ext3.......
Sous n'importe quel système l'allée principale, celle qui va tout droit, c'est le backup. Ensuite tu formates, restaures et on en parles plus. Redimentionner une partition, c'est déjà du bricolage
-- Nicolas
Le chat de personne <chat@LeSpamCestPasBien.invalid> wrote:
Non ce que je veux dire c'est qu'on utilise des chemins de traverse
alors que je ne trouve rien qui aille tout droit.
Pour que ça aille tout droit, il aurait fallu entrer par l'allée
principale et ne pas t'engager d'emblée dans de petites ruelles.
Parce que déjà, tu as du multiboot et ça même sous windows c'est pas
tout tracé d'avance, le MBR et tout ce merdier n'a rien de facile.
Ensuite tu as sauciçonné tes disques en de multiples partitions, sans
utiliser lvm, c'est un bon moyen pour se pendre dans le tapis.
Sous NTFS, tu reduit la partition, tu cree une partition sur la place
liberée, tu valide et c'est bon.
La seule fois que le l'ai fait, avec partition magic, ça a foiré, j'ai
perdu mes données.
Sous ext3.......
Sous n'importe quel système l'allée principale, celle qui va tout droit,
c'est le backup. Ensuite tu formates, restaures et on en parles plus.
Redimentionner une partition, c'est déjà du bricolage
Non ce que je veux dire c'est qu'on utilise des chemins de traverse alors que je ne trouve rien qui aille tout droit.
Pour que ça aille tout droit, il aurait fallu entrer par l'allée principale et ne pas t'engager d'emblée dans de petites ruelles.
Parce que déjà, tu as du multiboot et ça même sous windows c'est pas tout tracé d'avance, le MBR et tout ce merdier n'a rien de facile.
Ensuite tu as sauciçonné tes disques en de multiples partitions, sans utiliser lvm, c'est un bon moyen pour se pendre dans le tapis.
Sous NTFS, tu reduit la partition, tu cree une partition sur la place liberée, tu valide et c'est bon.
La seule fois que le l'ai fait, avec partition magic, ça a foiré, j'ai perdu mes données.
Sous ext3.......
Sous n'importe quel système l'allée principale, celle qui va tout droit, c'est le backup. Ensuite tu formates, restaures et on en parles plus. Redimentionner une partition, c'est déjà du bricolage
-- Nicolas
Nicolas George
Le chat de personne wrote in message :
Un binaire c'est un fichier non-texte qui a des caractere non-imprimable. Il ne peut pas etre affiché tel quel.
Oui. Et tout ceci n'implique pas du tout que ce ne sont pas fortement compressible.
Le chat de personne wrote in message
<a1tc231pobll0unjfpa1cclmfo05augef8@4ax.com>:
Un binaire c'est un fichier non-texte qui a des caractere
non-imprimable. Il ne peut pas etre affiché tel quel.
Oui. Et tout ceci n'implique pas du tout que ce ne sont pas fortement
compressible.
Un binaire c'est un fichier non-texte qui a des caractere non-imprimable. Il ne peut pas etre affiché tel quel.
Oui. Et tout ceci n'implique pas du tout que ce ne sont pas fortement compressible.
Le chat de personne
On Tue, 17 Apr 2007 22:31:48 +0200, Matthieu Moy wrote:
Dire « un binaire » pour « un binaire exécutable », c'est juste un abus de langage. C'est pas grave de le dire, mais c'est important de comprendre la différence entre les concepts.
Pour moi un binaire, c'est pas que executable. Un binaire c'est un fichier non-texte qui a des caractere non-imprimable. Il ne peut pas etre affiché tel quel. Les caracteres non imprimable (enfin plutot le le code qu'il represente) doit etre remplacé.
D'ailleur je cherche un viewer de binaire.....(qui ne fait pas editeur, je precise)
Maintenant, c'est vrai que les abus de languages sont sans doute plus fréquents chez le Windowsien moyen que chez le Linuxien moyen ;-).
Je le reconnais. Il en va de meme pour les lien symbolique. ;o))
Dire « un binaire » pour « un binaire exécutable », c'est juste un
abus de langage. C'est pas grave de le dire, mais c'est important de
comprendre la différence entre les concepts.
Pour moi un binaire, c'est pas que executable.
Un binaire c'est un fichier non-texte qui a des caractere
non-imprimable. Il ne peut pas etre affiché tel quel. Les caracteres
non imprimable (enfin plutot le le code qu'il represente) doit etre
remplacé.
D'ailleur je cherche un viewer de binaire.....(qui ne fait pas
editeur, je precise)
Maintenant, c'est vrai que les abus de languages sont sans doute plus
fréquents chez le Windowsien moyen que chez le Linuxien moyen ;-).
Je le reconnais.
Il en va de meme pour les lien symbolique.
;o))
On Tue, 17 Apr 2007 22:31:48 +0200, Matthieu Moy wrote:
Dire « un binaire » pour « un binaire exécutable », c'est juste un abus de langage. C'est pas grave de le dire, mais c'est important de comprendre la différence entre les concepts.
Pour moi un binaire, c'est pas que executable. Un binaire c'est un fichier non-texte qui a des caractere non-imprimable. Il ne peut pas etre affiché tel quel. Les caracteres non imprimable (enfin plutot le le code qu'il represente) doit etre remplacé.
D'ailleur je cherche un viewer de binaire.....(qui ne fait pas editeur, je precise)
Maintenant, c'est vrai que les abus de languages sont sans doute plus fréquents chez le Windowsien moyen que chez le Linuxien moyen ;-).
Je le reconnais. Il en va de meme pour les lien symbolique. ;o))
Le chat de personne
On Tue, 17 Apr 2007 22:40:59 +0200, Doug713705 wrote:
Alors ne demande pas comment gérer d'un seul clic la corbeille sous Linux ;-) et fais toi (par exemple) un script aux petits oignons qui le fait pour toi comme tu le souhaites (et non pas comme quelqu'un dans un pays lointain a décidé de ce qui est bon pour toi).
Les script c'est pas pour maintenant. Je suis encore en phase d'apprentissage et de teste de distri. (d'ailleur je trouve ubuntu pas mal et un peu plus rapide que mandriva)
Je comprends vite quand on m'explique longtemps....
On Tue, 17 Apr 2007 22:40:59 +0200, Doug713705
<nospam.doug.letough@free.fr.nospam> wrote:
Alors ne demande pas comment gérer d'un seul clic la
corbeille sous Linux ;-) et fais toi (par exemple) un script aux petits
oignons qui le fait pour toi comme tu le souhaites (et non pas comme
quelqu'un dans un pays lointain a décidé de ce qui est bon pour toi).
Les script c'est pas pour maintenant.
Je suis encore en phase d'apprentissage et de teste de distri.
(d'ailleur je trouve ubuntu pas mal et un peu plus rapide que
mandriva)
Je comprends vite quand on m'explique longtemps....
On Tue, 17 Apr 2007 22:40:59 +0200, Doug713705 wrote:
Alors ne demande pas comment gérer d'un seul clic la corbeille sous Linux ;-) et fais toi (par exemple) un script aux petits oignons qui le fait pour toi comme tu le souhaites (et non pas comme quelqu'un dans un pays lointain a décidé de ce qui est bon pour toi).
Les script c'est pas pour maintenant. Je suis encore en phase d'apprentissage et de teste de distri. (d'ailleur je trouve ubuntu pas mal et un peu plus rapide que mandriva)
Je comprends vite quand on m'explique longtemps....
Le chat de personne
On Tue, 17 Apr 2007 16:52:21 -0400, Denis Beauregard wrote:
Si ce n'est pas compressible et qu'on ne peut pas tout copier dans la même partition, il faut trouver une autre solution (stockage sur un serveur par FTP par exemple ou sur des DVD qu'on prendra le temps de relire avant d'effacer les originaux.
Je trouve dommage que ext3 ne soit pas aussi facile a deplacer (meme en partie par dessus lui meme)
Si ce n'est pas compressible et qu'on ne peut
pas tout copier dans la même partition, il faut trouver une autre
solution (stockage sur un serveur par FTP par exemple ou sur des
DVD qu'on prendra le temps de relire avant d'effacer les originaux.
Je trouve dommage que ext3 ne soit pas aussi facile a deplacer (meme
en partie par dessus lui meme)
On Tue, 17 Apr 2007 16:52:21 -0400, Denis Beauregard wrote:
Si ce n'est pas compressible et qu'on ne peut pas tout copier dans la même partition, il faut trouver une autre solution (stockage sur un serveur par FTP par exemple ou sur des DVD qu'on prendra le temps de relire avant d'effacer les originaux.
Je trouve dommage que ext3 ne soit pas aussi facile a deplacer (meme en partie par dessus lui meme)
Se serait telement plus simple.
Le chat de personne
On Wed, 18 Apr 2007 18:30:23 +0200, (Nicolas MICHEL) wrote:
Le chat de personne wrote:
Non ce que je veux dire c'est qu'on utilise des chemins de traverse alors que je ne trouve rien qui aille tout droit.
Pour que ça aille tout droit, il aurait fallu entrer par l'allée principale et ne pas t'engager d'emblée dans de petites ruelles.
Le probleme c'est que la porte donne directement sur les ruelles en ce moment. Je vais pas tout virer pour avoir une large allée principale. De toute facon tot ou tard j'aurrai ete confronté au probleme.
Parce que déjà, tu as du multiboot et ça même sous windows c'est pas tout tracé d'avance, le MBR et tout ce merdier n'a rien de facile.
Sous windows c'est pas un probleme. Sous linux je maitrise meme pas lilo ou grub.....
Ensuite tu as sauciçonné tes disques en de multiples partitions, sans utiliser lvm, c'est un bon moyen pour se pendre dans le tapis.
Non merci pas de volume. Meme pas sous windows.
Si t'as une partition qui degage.....
Sous NTFS, tu reduit la partition, tu cree une partition sur la place liberée, tu valide et c'est bon.
La seule fois que le l'ai fait, avec partition magic, ça a foiré, j'ai perdu mes données.
Partition magic n'est pas une reference. De plus ce genre d'outils faut jamais les utiliser sous windows mais en mode reel. Certe il n'y a pas de protection memoire, multitache, ETC ETC, mais moins il y a de bidule mieux ca marche.
Sous ext3.......
Sous n'importe quel système l'allée principale, celle qui va tout droit, c'est le backup.
Le backup c'est pas la panacé non plus. J'en ai pour une semaine a graver, tester, passer au suivant..... Et je vais pas acheter un disque dur de plus....
Ensuite tu formates, restaures et on en parles plus. Redimentionner une partition, c'est déjà du bricolage
Oui mais jusqu'a present je n'ai jamais eu de probleme meme en cas de coupure de courant. (faut pas utiliser partition magic sauf ptedit un petit bijou en cas de partition raw) Et dieu sait que c'est le bordel sur mes disques. Mais j'arrive (enfin j'arrivais) toujours a bricoler mes partitions.
Le chat de personne <chat@LeSpamCestPasBien.invalid> wrote:
Non ce que je veux dire c'est qu'on utilise des chemins de traverse
alors que je ne trouve rien qui aille tout droit.
Pour que ça aille tout droit, il aurait fallu entrer par l'allée
principale et ne pas t'engager d'emblée dans de petites ruelles.
Le probleme c'est que la porte donne directement sur les ruelles en ce
moment.
Je vais pas tout virer pour avoir une large allée principale.
De toute facon tot ou tard j'aurrai ete confronté au probleme.
Parce que déjà, tu as du multiboot et ça même sous windows c'est pas
tout tracé d'avance, le MBR et tout ce merdier n'a rien de facile.
Sous windows c'est pas un probleme. Sous linux je maitrise meme pas
lilo ou grub.....
Ensuite tu as sauciçonné tes disques en de multiples partitions, sans
utiliser lvm, c'est un bon moyen pour se pendre dans le tapis.
Non merci pas de volume.
Meme pas sous windows.
Si t'as une partition qui degage.....
Sous NTFS, tu reduit la partition, tu cree une partition sur la place
liberée, tu valide et c'est bon.
La seule fois que le l'ai fait, avec partition magic, ça a foiré, j'ai
perdu mes données.
Partition magic n'est pas une reference.
De plus ce genre d'outils faut jamais les utiliser sous windows mais
en mode reel. Certe il n'y a pas de protection memoire, multitache,
ETC ETC, mais moins il y a de bidule mieux ca marche.
Sous ext3.......
Sous n'importe quel système l'allée principale, celle qui va tout droit,
c'est le backup.
Le backup c'est pas la panacé non plus.
J'en ai pour une semaine a graver, tester, passer au suivant.....
Et je vais pas acheter un disque dur de plus....
Ensuite tu formates, restaures et on en parles plus.
Redimentionner une partition, c'est déjà du bricolage
Oui mais jusqu'a present je n'ai jamais eu de probleme meme en cas de
coupure de courant. (faut pas utiliser partition magic sauf ptedit un
petit bijou en cas de partition raw)
Et dieu sait que c'est le bordel sur mes disques. Mais j'arrive (enfin
j'arrivais) toujours a bricoler mes partitions.
On Wed, 18 Apr 2007 18:30:23 +0200, (Nicolas MICHEL) wrote:
Le chat de personne wrote:
Non ce que je veux dire c'est qu'on utilise des chemins de traverse alors que je ne trouve rien qui aille tout droit.
Pour que ça aille tout droit, il aurait fallu entrer par l'allée principale et ne pas t'engager d'emblée dans de petites ruelles.
Le probleme c'est que la porte donne directement sur les ruelles en ce moment. Je vais pas tout virer pour avoir une large allée principale. De toute facon tot ou tard j'aurrai ete confronté au probleme.
Parce que déjà, tu as du multiboot et ça même sous windows c'est pas tout tracé d'avance, le MBR et tout ce merdier n'a rien de facile.
Sous windows c'est pas un probleme. Sous linux je maitrise meme pas lilo ou grub.....
Ensuite tu as sauciçonné tes disques en de multiples partitions, sans utiliser lvm, c'est un bon moyen pour se pendre dans le tapis.
Non merci pas de volume. Meme pas sous windows.
Si t'as une partition qui degage.....
Sous NTFS, tu reduit la partition, tu cree une partition sur la place liberée, tu valide et c'est bon.
La seule fois que le l'ai fait, avec partition magic, ça a foiré, j'ai perdu mes données.
Partition magic n'est pas une reference. De plus ce genre d'outils faut jamais les utiliser sous windows mais en mode reel. Certe il n'y a pas de protection memoire, multitache, ETC ETC, mais moins il y a de bidule mieux ca marche.
Sous ext3.......
Sous n'importe quel système l'allée principale, celle qui va tout droit, c'est le backup.
Le backup c'est pas la panacé non plus. J'en ai pour une semaine a graver, tester, passer au suivant..... Et je vais pas acheter un disque dur de plus....
Ensuite tu formates, restaures et on en parles plus. Redimentionner une partition, c'est déjà du bricolage
Oui mais jusqu'a present je n'ai jamais eu de probleme meme en cas de coupure de courant. (faut pas utiliser partition magic sauf ptedit un petit bijou en cas de partition raw) Et dieu sait que c'est le bordel sur mes disques. Mais j'arrive (enfin j'arrivais) toujours a bricoler mes partitions.
