Marotte ⛧ a écrit 8780 commentaires

Oui mais il a dit qu’il voudrait le faire dans un temps raisonnable de l’ordre de la poignée de dizaines de minutes.

Tout marche donc tu upgrade sur des versions plus récentes pour le fun ? Oo

Pour VirtualBox comme pour beaucoup de logiciels, dans toutes les mises à jours il y a des corrections de failles de sécurité. C’est pas déconnant que de s’efforcer de suivre les différentes sorties d’un produit qu’on utilise (donc à les tester par là même).

Tu fais bien les mise à jour de ton OS, pourtant tout fonctionne ?

Pourquoi ne pas revenir à la version stable qui marchait, plutôt ?

Je dis oui, mais ça reste une bonne idée de tester d’abord la dernière version.

Ta formulation ne me semble pas exacte, du moins trompeuse.

tu as une copie de chaque version de chaque fichier

Non, les hardlinks ne te permettent pas de revenir en arrière…

Plusieurs hardlinks sont d’autres noms pour un même fichier. Donc effectivement dans le cadre de backup incrémentaux, si le 12 du mois tu as un fichier 'lefile.txt' dans ton backup, au backup d’après si ce fichier n’a pas été modifié il sera présent directement dans l’arbo du backup suivant via un hardlink. Ça s’arrête là.

Donc je dirais plutôt : « Tu as une seule copie de chaque fichier ».

c'était hyper long (j'ai abandonné des semaines après le commencement).

Essaye peut-être par lots, afin de valider la méthode ? Tout à l’heure j’allais te répondre que cp -a devrait copier les hardlinks tel quel (ce que tu veux) mais après lecture du man ce n’était plus si évident… m’enfin de mémoire il me semble bien que c’est le cas.

De toute façon 2To c’est 2To, que tu utilises dd, cp, rsync ou autre ça serait forcément relativement long de tout dupliquer.

Un autre avantage de le faire par lots c’est que tu peux éventuellement virer quelques trucs devenus sans intérêts au passage. Après je conçois tout à fait que l’on veuille « tout garder » mais bon, ça fait forcément de la « manutention », comme des meubles ou des bibelots !

Toujours aussi surprenants tes noms de programmes :)

Alors du coup je pense que c’est ni élégant, ni académique, ni efficient mais je m’en sort comme ça :

# Do find
do_find() {
cat <<EOF
find $* 2>/dev/null
EOF
}

La redirection de 2 vers /dev/null est bien entendu optionnelle mais pour l’instant je ne traite pas les fichiers inaccessibles.

J’utilise la fonction ainsi :

NEWER_FILES_NB=$(eval $(do_find $1 ${FIND_TYPE_CLAUSE} ${FIND_NAME_CLAUSE} -mmin -${MIN_AGE}) |wc -l)

ou encore :

    format="-printf '%s;%Cc;%p;%k kB;%Y\n'"
    firstlast=$(eval $(do_find $search ${FIND_TYPE_CLAUSE} ${FIND_NAME_CLAUSE} ${format}) |sort -n |awk 'BEGIN{FS=";"} {if (NR==1) print "(" $5 ")" $3 " (" $4 ") " $2} END{print "(" $5 ")" $3 " (" $4 ") " $2}')

(firstlast est un nom de variable très mal choisi, il s’agit en fait de la liste des fichiers sous forme de CSV)

Le dernier exemple fonctionne avec le find de GNU mais pas avec toutes les implémentations de find.

Avec cette méthode je dois échapper les caractères '(' et '!' pour find par contre. Enfin quand je dis je dois… pour les parenthèses oui mais le '!' passe, qu’il soit échappé ou pas… (vu que j’ai le choix je l’échappe)

La prochaine fois que je me dis, tiens et si je démarrais un projet en shell ? J’y réfléchirai à deux fois :)

Merci à tous pour vos réponses qui m’ont mis sur la voie.

Oui. C’est à un autre endroit dans mon script que je me prenais les pieds dans le globbing, getopts n’y est définitivement pour rien.

find_name_clause() {
            if [ $(expr length $1) -gt 2 ]
            then
                FIND_NAME_CLAUSE=" -name "$1
            fi
            if [ $(expr length $1) -gt 2 -a $(expr length $2) -gt 2  ]
            then
                FIND_NAME_CLAUSE=${FIND_NAME_CLAUSE}" -a "
            fi    
            if [ $(expr length $2) -gt 2  ]
            then
                FIND_NAME_CLAUSE=${FIND_NAME_CLAUSE}"! -name  "$2
            fi    
}
find_name_clause "'"${SEARCH_NAME_INCLUDE}"'" "'"${SEARCH_NAME_EXCLUDE}"'"

Vive le shell !

OSM does NOT pre-render every tile. Pre-rendering all tiles would use around 54 TB of storage.

Leur serveur aurait ça comme stockage :

/dev/sda
    2TB RAID1+0 array over 2 disks
/dev/sdb
    1TB RAID1+0 array over 2 disks
/dev/sdd
    600GB RAID1+0 array over 4 disks 

Il y n’y avait que : disk usage: 1272GB used. (6 Jan 2012). (z0 to z15: 252GB, z16 to z18: 1020GB)

Enfin tout ça pour dire qu’il ne faut peut-être pas un espace de stockage de plus de 50 To pour héberger un serveur de tuile, "juste" quelques To, pour commencer :)

Faut rassurer d’éventuels hébergeurs volontaires !

Et sur d’éventuels répertoires de cache, firefox par exemple, tu penses qu’il peut y avoir un gain ? Ou sur les téléchargements ?

C’est bien ntfs-3g qui est utilisé. Comme sur MacOS.

On peut monter automatiquement le disque dur de 1To au format NTFS avec /etc/fstab?

J’ose espérer que systemd respecte encore /etc/fstab :)

Pour la taille des partitions tu devrais vraiment te pencher sur LVM, c’est quand même sacrément pratique…

Avec LVM tu fais un PV (volume physique) sur chacun de tes disques. Sur chacun de ces volumes physiques tu créés des volumes logiques, comme tu créerais des partitions en mode « traditionnel ». Pour ces volumes logiques tu choisis la taille minimale, tu n’utilises donc pas tout le volume physique… car quand tu auras besoin de place tu pourrais très facilement augmenter l’un des volumes (puis le FS qu’il abrite), tu ne seras pas bloqué par des considérations d’ordre de partitions, de table de partitions…

Ce n’est qu’un exemple simple de ce que l’on peut faire avec LVM mais je trouve que c’est une configuration qui apporte beaucoup même pour un desktop.

Si tu t’apprêtes à installer un système, cette configuration est supportée par tous les installeurs des grandes distributions. On peut le configurer à l’installation et ce n’est pas très compliqué si tu as lu un minimum de doc avant.

Bah oui en plus ça règle ton problème de format de partition pour le partage, tu mets /data en NTFS.

J'ai acheté un SSD pour mettre Windows et un pour Linux de 250 Go chacun. Un autre disque de 1T sert de /home pour la sauvegarde des données.

Je pense que si j’avais un SSD de 250 Go et un disque de 1To je laisserais le /home sur le SSD et monterais le disque de 1To sur son propre point de montage (ex: /data). Ainsi tous les gros fichiers (musique, vidéo, etc…) iraient sur /data mais tous les fichiers de configuration du /home resteraient sur le SSD, ce qui doit permettre de profiter aussi de la vitesse de lecture pour ces fichiers de configuration.

Pour mes principaux déplacements quotidiens, j'utilise en majorité :

Permettre plusieurs réponses à cette question n’aurait aucun sens.

Merci pour la correction. Je trouve en effet que l’interface VirtualBox est un peu plus aboutie que celle de virt-manager. Donc si on peut utiliser KVM avec VirtualBox c’est cool. Je ne le savais pas, je n’utilise VirtualBox que sous Windows.

Reste que VirtualBox c’est Oracle et que tout n’est pas libre.

Tu utilises bien la 5.1.2 sortie hier ? Sinon essaye, p-e que ce bug a été corrigé.

Sinon, même remarque que les autres, KVM c’est mieux.

C’est bien ce que j’imaginais… Mais alors du coup c’est quoi la surface métallique ? Est-ce qu’on utilise de l’aluminium pour sa caractéristique paramagnétique ou bien un alliage contenant du fer ?

Je sais que je devrais STFW mais je sais aussi que tu es calé en physique donc je demande quand même ;)

On peut magnétiser du verre ?

[doublon, supprimé]

J’espère que quelqu’un de plus calé que moi pourra te donner une solution mais pour ma part je pense que ce n’est pas possible. Il faudrait que l’espace libre se situe après sdc9 pour pouvoir augmenter le FS…

Donc à moins de supprimer sdc9 et sdc10 pour les recréer je vois pas.

Perso, j’utilise systématiquement LVM depuis plusieurs années à cause de ce genre de problématique…

beaucoup plus rapide

oui

encore faut-il que le disque soit reconnu par la machine

oui

Je n’avais pas pensé à ces points, merci d’avoir pris le temps de me répondre.

Alors du coup j’ai une autre question débile. Est-ce que tordre ou casser le plateau n’irait pas encore plus vite que de le rayer consciencieusement ? :)

et en rayant consciencieusement la surface des disques.

lol, j’espère que c’est de l’humour ;)

Si t’as déjà demonté le disque pour récupérer l’aimant faut vraiment que t’aies des données de la plus haute importance (genre méga-top-secret-défense) pour qu’un gus remonte les plateaux pour tenter de récupérer des données… En cas de paranoïa, un simple shred (logiciel !) va déjà rendre très (mais alors très très…) difficile la moindre récupération de donnée.

Ça changerait quoi ?

De l’eau ?

ChaletOS est une distribution Linux "débutant-friendly" basée sur Xubuntu, avec le bureau Xfce.
Elle fournit une interface de bureau simple et intuitive.
Les exigences matérielles sont modestes et elle bénéficie de cinq ans de soutien à la sécurité.

Bah… comme Xubuntu, qui est déjà un "reboot" pas trop officiel de Ubuntu, distribution elle même fortement dépendante de Daubian ?

Le nom ChaletOS provient des maisons des montagnes suisses dont les concepts de simplicité, de beauté et de symétrie ont inspiré la création et la conception de ChaletOS.

Je ne sais pas si de mon vivant je verrais BunkerOS, TipiOS et MasDeProvenceOS… mais j’ai bon espoir… je sais que la vie est faite de surprises.