[Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

Aldian · Le 21/07/2010, à 11:50

Bon alors j'ai fait les chronos. A chaque fois je fais ça sur une taille de 2GB en espérant que les peturbations liées au systèmes seront noyées dans la masse, mais comme chaque opération dure dans les 6 min, je ne peux pas commencer à faire plusieurs chronos de chaque et à faire une moyenne sans quoi j'y passe la journée. Ce préambule établi, voici les résultats :

Avec la correction d'Hizoka: 7m00s46 (place restante: 0 )

Avec la suggestion de ǤƦƯƝƬ intégrée de la manière suivante: 6m17s21 (place restante: 47Mio)

entree="$1"
sortie="$2"

# boucle lisant les mp3 1 par 1
while read mp3
do
 # Taille du fichier de destination
 taille=$(du -s "${mp3}" | sed 's/\t.*//')

 # Comptabilise la taille restante sur la clé
 taille_restante=$(df  | grep UDISK | awk '{print $4}')
 echo $taille_restante

 # verifie que la taille du fichier est inferieure à l'espace disponible
 # perf 6m17s21    47,4Mio libres
 if [[ ${taille} -lt ${taille_restante} ]]
 then
   # si c'est vrai, on copie le fichier
   cp "${mp3}" "${sortie}"
 else
  # on arrête la boucle, ou "exit" pour quitter le script....
  break
 fi
# envoie du retour de la recherche de mp3 suivit du mélange de ceux ci dans la boucle
done < <(find "${entree}" -type f -iname '*.mp3' | sort -R)

Avec la suggestion de ǤƦƯƝƬ intégrée de la manière suivante: 7m08s98 (place restante: 0 )

entree="$1"
sortie="$2"

# boucle lisant les mp3 1 par 1
while read mp3
do
 # Regarde combien il reste de place
 taille_restante=$(df  | grep UDISK | awk '{print $4}')
 echo $taille_restante

 # verifie qu'il reste au moins 5 Mo sur le disque (sachant que des fichiers de plus grande tailles génèreront des warnings non interruptifs)
 # perf 7m08s98          
 if [[ 5000 -lt ${taille_restante} ]]
 then
   # si c'est vrai, on copie le fichier
   cp "${mp3}" "${sortie}"
 else
  # on arrête la boucle, ou "exit" pour quitter le script....
  break
 fi
# envoie du retour de la recherche de mp3 suivit du mélange de ceux ci dans la boucle
done < <(find "${entree}" -type f -iname '*.mp3' | sort -R)

C'est le dernier chrono qui me parait bizarre, logiquement on aurait encore du gagner en temps d'exécution

Grünt · Le 21/07/2010, à 11:53

Tu peux affiner en cherchant des petits fichiers pour remplir l'espace disponible

twocats · Le 21/07/2010, à 12:39

On peut simplifier et modifier certains passages :

taille=$(du -s "${mp3}" | sed 's/\t.*//')

en

taille=$(du -s "${mp3}" | awk '{print $1}')

et

taille_restante=$(df -P  | grep UDISK | awk '{print $4}')

en

taille_restante=$(df -P | awk '/UDISK/ {print $4}')

awk est plus rapide que sed et grep. Le '-P' de df est là pour la conformité POSIX en cas de partitions cryptées avec des noms 'alacon'.
Et virer le 'break' qui n'a rien à faire ici par un 'exit' !

kamui57 · Le 21/07/2010, à 12:40

On en apprend des choses

Grünt · Le 21/07/2010, à 13:28

twocats a écrit :

Et virer le 'break' qui n'a rien à faire ici par un 'exit' !

\o/

Hizoka · Le 21/07/2010, à 13:36

Avec la correction d'Hizoka: 7m00s46 (place restante: 0 )

Coup de chance pour le 0 restant

en effet avec df je pensais que ça serait plus rapide...

twocats a écrit :

awk est plus rapide que sed et grep.

for i in {1..100}
do
du -s Zenitor | sed 's/\t.*//'
done
=> real    0m0.203s

Va de 0.180 a 0.210s

for i in {1..100}
do
du -s Zenitor | awk '{print $1}'
done
=> real    0m0.202s

environ 0.210s...

for i in {1..100}
do
test=($(du -s Zenitor))
done
=> real    0m0.198s

environ 0.200s

for i in {1..100}
do
df -P  | grep "sdb6" | awk '{print $4}'
done
=> real    0m0.176s

environ 0.180s

for i in {1..100}
do
df -P | awk '/sdb6/ {print $4}'
done
=> real    0m0.212s

environ 0.200s...

bon, comme tu peux le voir, on ne peut pas vraiment dire que c'est different...

hop, j'ajoute ces tests sur : http://forum.ubuntu-fr.org/viewtopic.php?pid=3614938

twocats a écrit :

Et virer le 'break' qui n'a rien à faire ici par un 'exit' !

pas d'accord, j'ai mis break car si jamais il veut ajouter d'autres commande apres la boucle, au moins ca marchera, il cherchera pas d'ou vient le problème...
et qu'est-ce que ça change réellement ?

Dernière modification par Hizoka (Le 21/07/2010, à 13:47)

twocats · Le 21/07/2010, à 14:22

df -P  | grep "sdb6" | awk '{print $4}'

Trois commandes, deux pipes.

df -P | awk '/sdb6/ {print $4}'

Deux commandes, un pipe.
Je ne voudrais pas mettre en doute la validité de tes tests mais il me parait curieux que la seconde opération nécessitant un appel en moins et un sous-shell en moins prenne plus de temps que la première...

Totor · Le 21/07/2010, à 14:26

Bonjour,

Voici une version non testée (car pas de système unix sous la main):

entree="$1"
sortie="$2"

# boucle lisant les mp3 1 par 1
while read
do
 mp3="${REPLY#*;}"
 taille="${REPLY%%;*}"

 # Regarde combien il reste de place
 { read; read -a taille_restante ; } < <(df "${sortie}")
 ((${taille} <= ${taille_restante[3]})) && cp "${mp3}" "${sortie}" || break
# envoie du retour de la recherche de mp3 suivit du mélange de ceux ci dans la boucle
done < <(find "${entree}" -type f -iname '*.mp3' -printf "%s;%p" | sort -R)

j'ai des doutes sur la ligne { read; read -a taille_restante ; } < <(df "${sortie}") car il y a déjà une entrée standard d'exploitée avec celui de la boucle.
Si cela ne fonctionne pas, on peut effectuer comme ceci taille_restante=( $(df "${sortie}") ) puis changer l'indice dans la condition qui suit (normalement, ce devrait être 10 si l'on se fit à la sortie de df comme indiquée ici).

A noter également la transformation du if then else par un condition && action || action afin de stoper le processus en cas d'erreur de copie (pour une quelconque raison)

EDIT : autre version

entree="$1"
sortie="$2"

# boucle lisant les mp3 1 par 1
{ read; read -a taille_restante ; } < <(df "${sortie}")
taille_restante=${taille_restante[3]}
while read
do
 mp3="${REPLY#*;}"
 taille="${REPLY%%;*}"

 ((${taille} <= ${taille_restante})) && cp "${mp3}" "${sortie}" || break
 ((taille_restante-=taille))
# envoie du retour de la recherche de mp3 suivit du mélange de ceux ci dans la boucle
done < <(find "${entree}" -type f -iname '*.mp3' -printf "%s;%p" | sort -R)

Dernière modification par Totor (Le 21/07/2010, à 18:18)

Hizoka · Le 21/07/2010, à 14:40

twocats => je suis d'accord avec toi mais, time me renvoi des valeurs egale ou superieures quand meme....

hé hé totor a mis un break

twocats · Le 21/07/2010, à 19:25

#!/bin/bash

# Variables
MP3=0
MP3SIZE=0

# Début du script
[[ "${TERM}" ]] && clear

while getopts :i:o:-: option
do
	if [[ "$option" = "-" ]]
	then
		case $OPTARG in
			input ) option=i ;;
			output ) option=o ;;
			* ) echo "Option $OPTARG inconnue"; exit 1 ;;
		esac
	fi
	case $option in
		i ) INPUT="$OPTARG" ;;
		o ) OUTPUT="$OPTARG" ;;
		* ) echo "Option $OPTARG inconnue"; exit 1 ;;
	esac
done
shift $(($OPTIND - 1))

FOLDERSIZE=$(df -P "${OUTPUT}" | awk '(NR!=1) {print $4}')

while [[ "${MP3}" ]]
do
# On cherche un mp3 avec une taille inférieure à l'espace disque disponible
MP3=$(find "${INPUT}" -type f -size -${FOLDERSIZE}k -iname \*.mp3 -printf "%s;%p\n" | sort -R | head -1)
MP3NAME="${MP3#*;}"
MP3SIZE="${MP3%%;*}"
# On vérifie que le fichier n'a pas déjà été copié et on copie
[[ ! -e "${OUTPUT}""${MP3NAME##*/}" ]] && cp "${MP3NAME}" "${OUTPUT}"
# Comptabilise la taille restante sur la clé
FOLDERSIZE=$(df -P "${OUTPUT}" | awk '(NR!=1) {print $4}')
echo ${FOLDERSIZE}
done

echo "On passe les commandes suivantes. Et pas besoin de 'break' !"

Bon voilà, aucune des solutions ne me plaisait alors je propose la mienne. La syntaxe propose un système d'option avec argument; c.a.d. :

script.sh -i dossier_d'entree -o dossier_de_destination

Dernière modification par twocats (Le 21/07/2010, à 19:25)

Hizoka · Le 21/07/2010, à 21:14

c'est excellent

un "problème" une infinité de solution

Totor · Le 21/07/2010, à 21:16

@twocats
Certe, ta méthode à l'avantage de remplir au maximum le disque mais c'est au sacrifice des performances.

Pour cette histoire de "break ou exit", j'appuie Hizoka. Le break est le plus adapté (même si je ne suis pas fan).

Si tu y es vraiment allergique, il suffit de modifier légèrement nos codes pour le supprimer :

entree="$1"
sortie="$2"

{ read; read -a taille_restante ; } < <(df "${sortie}")
taille_restante=${taille_restante[3]}
encore=true

# boucle lisant les mp3 1 par 1
while { ${encore} && read ; }
do
 mp3="${REPLY#*;}"
 taille="${REPLY%%;*}"

 ((${taille} <= ${taille_restante})) && cp "${mp3}" "${sortie}" || encore=false
 ((taille_restante-=taille))
# envoie du retour de la recherche de mp3 suivit du mélange de ceux ci dans la boucle
done < <(find "${entree}" -type f -iname '*.mp3' -printf "%s;%p" | sort -R)

note cecie devrait fonctionner while ${encore} && read mais ne pouvant tester, je préfère assurer avec while { ${encore} && read ; }

Hizoka · Le 21/07/2010, à 21:35

while { ${encore} && read ; }

à quoi sert le read ; ?

mp3="${REPLY#*;}"

comment connait-il reply ? C'est une variable automatiquement crée ?

((taille_restante-=taille))

à quoi sert le = ?

find "${entree}" -type f -iname '*.mp3' -printf "%s;%p"

je ne pige pas l’intérêt du printf, ça colle toutes les adresses à la suite mais comment le while arrive-t-il à à comprendre les adresse ?

Totor · Le 21/07/2010, à 22:03

Hizoka a écrit :

while { ${encore} && read ; }
à quoi sert le read ; ?

man bash a écrit :

(liste)
liste est exécutée dans un sous-shell. Les affectations de variables, et les commandes internes qui affectent l'environnement de l'interpréteur n'ont pas d'effet une fois que la commande se termine. Le code de retour est celui de la liste.
{ liste; }
liste est simplement exécutée avec l'environnement du shell en cours. liste doit se terminer par un caractère fin-de-ligne ou un point-virgule. Cette construction est connue sous le nom de commandes groupées. Le code de retour est celui de la liste.

Hizoka a écrit :

mp3="${REPLY#*;}"
comment connait-il reply ? C'est une variable automatiquement crée ?

man bash a écrit :

read [...]
Si aucun nom n'est fourni, la ligne lue est affectée entièrement à la variable REPLY. Le code de retour est nul, sauf si une fin-de-fichier est rencontrée.
[...]

De plus, ne pas utiliser de nom permet de récupérer la totalité des informations. Pour comprendre, effectue ce test :

echo " lettre a  " > unfichier.test
read a < unfichier.test
echo "-${a}-"
read < unfichier.test
echo "-${REPLY}-"
rm unfichier.test

Hizoka a écrit :

((taille_restante-=taille))
à quoi sert le = ?

Cette notation permet de soustraire taille à taille_restante tout en l'affectant à taille_restante (notation C)

Hizoka a écrit :

find "${entree}" -type f -iname '*.mp3' -printf "%s;%p"
je ne pige pas l’intérêt du printf, ça colle toutes les adresses à la suite mais comment le while arrive-t-il à à comprendre les adresse ?

Erreur de ma part : find "${entree}" -type f -iname '*.mp3' -printf "%s;%p\n"

Dernière modification par Totor (Le 21/07/2010, à 22:09)

Hizoka · Le 22/07/2010, à 00:01

ok, merci pour les infos, en effet je ne maîtrise pas du tout les read comme tu les utilises...

Aldian · Le 22/07/2010, à 10:34

twocats, tu obtiens un chrono de 6m45s33

Totor, désolé, mais aucun de tes scripts ne marchent. Ils s'arrêtent sans rien copier. J'ai placé des echo par ci par là, et je soupçonne une gamelle du genre "la taille des fichiers est en ko alors que la taille du répertoire est en Mo", mais sans certitude

edit: Après avoir bien examiné vos scripts, écouté vos explications très instructives sur la différence entre {} et () pour les tests, et procédé à quelques recherches, j'ai élaboré ma propre proposition, que vous allez sans doute trouver dangereuse car un peu trop simplifiée. La performance obtenue est de 6m37s01:

entree="$1"
sortie="$2"
error=0

# boucle lisant les mp3 1 par 1
while { read mp3 && [ ${error} -eq 0 ] ;}
do
 echo "${mp3}"
 cp "${mp3}" "${sortie}"
 error=$?
 
# envoie du retour de la recherche de mp3 suivit du mélange de ceux ci dans la boucle
done < <(find "${entree}" -type f -iname '*.mp3' | sort -R)

Bon il est clair que le facteur limitant n'est pas le nombre d'instruction mais le temps nécessité par la copie de tous les fichiers. Je me demande s'il n'y a pas moyen de l'améliorer, il me sembler bien que lors de copies massives de fichiers, le système est plus rapide que ça..

Dernière modification par Aldian (Le 22/07/2010, à 11:14)

Grünt · Le 22/07/2010, à 11:25

Aldian a écrit :

Bon il est clair que le facteur limitant n'est pas le nombre d'instruction mais le temps nécessité par la copie de tous les fichiers. Je me demande s'il n'y a pas moyen de l'améliorer, il me sembler bien que lors de copies massives de fichiers, le système est plus rapide que ça..

Oui, mais là ce n'est pas une copie massive, c'est une succession de copies une par une.
Ça doit changer quelque chose au niveau de la gestion du cache et des mouvements de la tête de lecture, non?
Sans compter qu'entre chaque copie on a des accès en lecture au système de fichier (pour déterminer les tailles, le type de fichier, l'espace restant).
Je pense que générer une liste de fichiers à copier, et ensuite copier ces fichiers, devrait gagner un peu.

Aldian · Le 22/07/2010, à 11:39

C'est ce que je viens de tester, mais en fait que dalle, j'obtiens un chrono de 6m32s01 pour le script suivant qui est très inspiré d'Hizoka (car c'est l'un des seuls qui ne dépende commandes sur le disque usb):

#!/bin/bash

entree="$1"
sortie="$2"

if [ ! -e tmp ]
   then mkdir tmp
fi

# boucle lisant les mp3 1 par 1
while read mp3
do
 # Taille du fichier de destination
 taille=$(du -s "${mp3}" | sed 's/\t.*//')

 # Comptabilise la taille totale des fichiers, évite de lister tout le dossier de sortie
 taille_totale=$((${taille_totale:-0} + ${taille}))
 echo $taille_totale

 # verifie que la taille du dossier est inferieur à 4go approximativement à adapter à la bonne taille
 # perf 7m00s46
 if [[ ${taille_totale} -lt 2000000 ]]
 then
   # si c'est vrai, on copie le fichier
   mv "${mp3}" tmp/
 else
  # on arrête la boucle, ou "exit" pour quitter le script....
  break
 fi
# envoie du retour de la recherche de mp3 suivit du mélange de ceux ci dans la boucle
done < <(find "${entree}" -type f -iname '*.mp3' | sort -R)

cd tmp/
cp * "${sortie}"
mv * ../

Il y a surement moyen d'optimiser la copie en masse, mais apparemment le système ne le fait pas par défaut

edit: j'ai essayé de remplacer cp * "${sortie}" par rsync -a . "${sortie}", mais pas d'amélioration notable, chrono 6m41s76

edit2: Bon pour la forme, j'ai fait la copie à la main façon système, et en fait c'est pas plus optimisé. Donc je pense qu'on peut abandonner l'optimisation, à moins d'utiliser une clé usb plus rapide on n'aura pas mieux.

Dernière modification par Aldian (Le 22/07/2010, à 12:46)

obibann · Le 22/07/2010, à 12:03

Pour gagner du temps, parcourir directement la liste des fichiers déjà dans un ordre aléatoire et sans doublons :

for i in `ls *.mp3`; do echo "$RANDOM;$i"; done | sort -t";" -k1 | cut -d";" -f2

Ensuite il n'y a plus qu'à copier la liste jusqu'à atteindre les 4Go

Dernière modification par obibann (Le 22/07/2010, à 12:06)

Grünt · Le 22/07/2010, à 13:28

Pourquoi ne pas copier sans vérifier, vu que de toute façon, la copie s'arrête quand c'est plein?

Aldian · Le 22/07/2010, à 13:31

C'est un peu ce que j'ai fait dans certains de mes essais. L'ennui, c'est que le script lui par contre ne s'arrête pas forcément tout seul, et qu'il continue jusqu'au bout à mettre dans la console les messages d'erreur disant qu'il n'a pas pu copier. Donc si il a une liste de 1500 fichiers dont il ne peut copier qu'environ 350, ça fait tout de même pas mal de gachis...

obibann · Le 22/07/2010, à 13:48

Aldian a écrit :

C'est un peu ce que j'ai fait dans certains de mes essais. L'ennui, c'est que le script lui par contre ne s'arrête pas forcément tout seul, et qu'il continue jusqu'au bout à mettre dans la console les messages d'erreur disant qu'il n'a pas pu copier. Donc si il a une liste de 1500 fichiers dont il ne peut copier qu'environ 350, ça fait tout de même pas mal de gachis...

Essaie ça :

repsource=/my/dir
repcible=/my/cible

cd $repsource

for i in `ls *.mp3`; do echo "$RANDOM;$i"; done | sort -t";" -k1 | cut -d";" -f2 | while read file ; do cp -f $file $repcible ; if [ $? != 0 ] ; then echo "DISK FULL" ; exit ; fi ; done

Dernière modification par obibann (Le 22/07/2010, à 13:51)

Totor · Le 22/07/2010, à 21:14

Aldian a écrit :

Totor, désolé, mais aucun de tes scripts ne marchent. Ils s'arrêtent sans rien copier. J'ai placé des echo par ci par là, et je soupçonne une gamelle du genre "la taille des fichiers est en ko alors que la taille du répertoire est en Mo", mais sans certitude

je vois ça dès mon retour de congès (ce WE)

Grünt · Le 22/07/2010, à 22:15

@obibann:
Ta solution a l'air parfaite

Totor · Le 23/07/2010, à 00:23

ǤƦƯƝƬ a écrit :

@obibann:
Ta solution a l'air parfaite

Pourtant il s'agit d'une usine à gaz : lister des fichiers avec ls dont le pattern est connu, puis générer des nombres, puis trier, puis extraire les noms de fichiers est complétement inutile.

Si l'on part du principe que tous les mp3 sont dans le même dossier, alors effectivement on peut se passer de la commande find (sauf que, explications ci-dessous) et cela peut être remplacé par ceci :

repsource=/my/dir
repcible=/my/cible

cd $repsource

while read
do
  cp "${REPLY}" "${repsource}" || break;
done < <(sort -R <(printf "%s\n" *.mp3))

d'autre part, exploiter le code retour <> 0 de cp comme déterminant du remplissage du support cible n'a pas de validité. la copie peut retourner un status <> 0 pour erreur de lecture, problème de droit sur le fichier source... je ne dis pas qu'il ne faut pas s'arrêter si cp retourne un status <> 0 (je me contredirai) mais simplement : dire que si le status de cp est <> 0 alors le disque est plein est un raccourci.

et puis tenter la copie est probablement moins rapide que de vérifier la quantité d'espace restante...

Pourquoi find peut être nécessaire (mais pas indispensable) : dans le cas où la taille des noms de fichiers mp3 dépasse 128k (cf. http://forum.ubuntu-fr.org/viewtopic.php?id=408294). Si c'est le cas, l'expansion par bash du pattern *.mp3 ne pourra aboutir et find devra être utilisé. (ou bien ls | grep '\.mp3$' mais il y aurait 1 processus inutile)

Dernière modification par Totor (Le 23/07/2010, à 00:25)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 21/07/2010, à 11:50

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#27 Le 21/07/2010, à 11:53

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#28 Le 21/07/2010, à 12:39

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#29 Le 21/07/2010, à 12:40

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#30 Le 21/07/2010, à 13:28

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#31 Le 21/07/2010, à 13:36

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#32 Le 21/07/2010, à 14:22

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#33 Le 21/07/2010, à 14:26

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#34 Le 21/07/2010, à 14:40

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#35 Le 21/07/2010, à 19:25

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#36 Le 21/07/2010, à 21:14

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#37 Le 21/07/2010, à 21:16

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#38 Le 21/07/2010, à 21:35

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#39 Le 21/07/2010, à 22:03

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#40 Le 22/07/2010, à 00:01

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#41 Le 22/07/2010, à 10:34

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#42 Le 22/07/2010, à 11:25

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#43 Le 22/07/2010, à 11:39

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#44 Le 22/07/2010, à 12:03

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#45 Le 22/07/2010, à 13:28

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#46 Le 22/07/2010, à 13:31

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#47 Le 22/07/2010, à 13:48

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#48 Le 22/07/2010, à 21:14

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#49 Le 22/07/2010, à 22:15

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

#50 Le 23/07/2010, à 00:23

Re : [Résolu]Comment sélectionner aléatoirement 4 GB de fichiers mp3?

Pied de page des forums