rsync vs cp, strace και άλλες αλχημείες

[alkisg]

Βλέπουμε ότι στην 2η περίπτωση η διαφορά ανάμεσα στους χρόνους της CP και της Rsync είναι σχεδόν ανύπαρκτη, οι χρόνοι είναι συνολικά πολύ μικρότεροι και η rsync εξακολουθεί να χρησιμοποιεί πολύ περισσότερη CPU.

7-8 δευτερόλεπτα η rsync (πόσο βγαίνει ο μέσος όρος) και 10-11 η cp είναι διαφορά... Δοκίμασε με κάτι μεγαλύτερο για να έχεις μικρότερη απόκλιση στις μετρήσεις.

 

Πάντως εγώ στο δικό μου μηχάνημα δεν είδα διαφορά...

Τρέχω cp, αργεί πολύ.

Τρέχω rsync, κάνει το μισό χρόνο.

Ξανατρέχω cp (μήπως ήταν θέμα caching η διαφορά) και τελειώνει ελαφρώς γρηγορότερα από την rsync.

Άρα στο δικό μου τουλάχιστον μηχάνημα (core 2 duo, sata) χρειάζονται περίπου τον ίδιο χρόνο, αν εξαιρέσουμε την πρώτη φορά που δεν υπήρχε τίποτα buffered.

 

>
alkisg@alkisgL:~$ time cp -rp Desktop/ /tmp

real	2m1.071s
user	0m0.616s
sys	0m8.549s
alkisg@alkisgL:~$ rm -rf /tmp/Desktop/
alkisg@alkisgL:~$ time rsync -rpE Desktop/ /tmp/Desktop
skipping non-regular file "Έγγραφα"
skipping non-regular file "flex/flex_sdk_3/runtimes/air/mac/Adobe AIR.framework/Adobe AIR"
skipping non-regular file "flex/flex_sdk_3/runtimes/air/mac/Adobe AIR.framework/Frameworks"
skipping non-regular file "flex/flex_sdk_3/runtimes/air/mac/Adobe AIR.framework/Resources"
skipping non-regular file "flex/flex_sdk_3/runtimes/air/mac/Adobe AIR.framework/Versions/Current"
skipping non-regular file "klibc-1.5.10/linux"
skipping non-regular file "klibc-patch1/klibc/linux"
skipping non-regular file "klibc/linux"
skipping non-regular file "newipconfig/klibc-1.5.10/linux"
skipping non-regular file "newipconfig/klibc-1.5.9/linux"

real	1m35.219s
user	0m9.101s
sys	0m9.425s
alkisg@alkisgL:~$ rm -rf /tmp/Desktop/
alkisg@alkisgL:~$ time cp -rp Desktop/ /tmp

real	1m28.232s
user	0m0.416s
sys	0m6.924s

Τα "skipping non regular file ..." ήταν για κάτι symlinks, δεν παίζουν ρόλο, το τελικό μέγεθος της αντιγραφής ήταν 923Mb και στις δύο περιπτώσεις, αρκετά μεγάλο για να είναι ψιλοαξιόπιστο (=επαναλήψιμο) το αποτέλεσμα.

 

 

Υ.Γ. #1 Tι block size έχει το RAID 0? (dumpe2fs)

 

Υ.Γ. #2: Apoike, θα με κάνεις να μην πάω διακοπές για να κάτσω να μάθω καλύτερα Linux! ;-) Μόλις "ανακάλυψα" την strace! Καλά δεν μπορείς να φανταστείς πόσα χρόνια παραπονιόμουνα που δεν είχαν κάτι τέτοιο ενσωματωμένο τα Windows...

[nske]

Πολύτιμο μάθημα μεθοδικής σκέψης και γνώσεων για το πώς δουλεύουν τα πράγματα από πίσω η απάντηση του Apoikou, ακριβώς αυτό που ήλπιζα

 

μπορείς να επιβεβαιώσεις ότι και στο raid διαβάζει/γράφει η cp με 8k/φορά;

 

Ναι, έτσι γράφει.

 

Υ.Γ. #1 Tι block size έχει το RAID 0? (dumpe2fs)

Η dumpe2fs βγάζει πληροφορίες μόνο για το filesystem που βρίσκεται σε ένα block device, το οποίο έχει δική του κατανομή σε blocks (στο ext2/3, σε ευμεγέθη filesystems, όπως στη δική μου περίπτωση, επιλέγεται by default 4K block size κατά τη δημιουργία). Δεν ασχολείται με τις λεπτομέρειες του block device στο οποίο κάθεται (στην προκειμένη το raid array). Το μέγεθος των chunks των active RAID arrays φαίνεται από το /proc/mdstat ή με mdadm --detail, σε μένα είναι 64K.

 

2 ακόμη tests στο πρώτο (non-smp) μηχάνημα, αυτή τη φορά χωρίς raid

 

http://nske.hackbox.gr/atch/rsync_unip_noraid.txt

http://nske.hackbox.gr/atch/cp_unip_noraid.txt

 

Εδώ μάλλον επαληθεύεται η συμπεριφορά που εμφανίζεται και στο μηχάνημα του Alkisg.

 

Οπότε το φαινόμενο όντως φαίνεται να έχει να κάνει με τον τρόπο που χειρίζεται τα δεδομένα το raid0.

 

ΥΣ. Νομίζω θα άξιζε ένα split στο topic

[gtroza]

θα με κάνεις να μην πάω διακοπές για να κάτσω να μάθω καλύτερα Linux! ;-)

 

goto διακοπές, όλοι !

.

[alkisg]

Το μέγεθος των chunks των active RAID arrays φαίνεται από το /proc/mdstat ή με mdadm --detail, σε μένα είναι 64K.

Sorry για την ασχετίλα στις εντολές.

 

Πάντως αφού cp buffer < block size, λογικά φταίει αυτό. Το ελάχιστο αποδεκτό είναι buffer = 2*block size ώστε να πιάνει και την περίπτωση να πέφτει η εγγραφή ανάμεσα σε 2 blocks. Μήπως να στείλεις ένα bug report στους developers της cp και να τους πεις να κοιτάνε το block size και στα raid?

[apoikos]

alkisg,

 

η strace είναι από τα πιο χρήσιμα εργαλεία, μαζί με τον gdb, για debugging. Εγώ να δεις απορία που είχα όταν έμαθα ότι δεν υπάρχει κάτι (σοβαρο) αντίστοιχο στα windows ;-)

 

Από 'κει και έπειτα, προσωπικά το θεωρώ όντως bug, αν και δεν ξέρω κατά πόσο μπορεί ένα κοινό userspace πρόγραμμα να «δει» το block size του RAID. Θα το μελετήσω λίγο ακόμα, με μερικές δοκιμές σε RAID-5 και μετά θα το αναφέρω.

[firewalker]

Δηλαδή η cp "αγνοεί" το block size του raid 0; Σε υποθετικό σύστημα χωρίς raid αλλά με custom block size > cp buffer θα έκανε το ίδιο;

 

Οι άλλες εντολές (π.χ. mv) τι κάνουν;

[apoikos]

Δεν ξέρω αν έχει τόση σχέση με το block size, μάλλον περισσότερη σχέση έχει με το readahead των δίσκων. Κάθε φορά που διαβάζει κάτι ο δίσκος, «φέρνει» και ένα προκαθορισμένο αριθμό από τα επόμενα blocks σε περίπτωση που αυτά ζητηθούν. Είναι λογικό το readahead, εφόσον διαβάζεις από 2 δίσκους διαφορετικά κομμάτια του αρχείου ταυτόχρονα, να είναι μεγαλύτερο στο RAID-0 απ' ότι στον έναν απλό δίσκο. Απλά αυτά τα θέματα είναι εξαιρετικά πολύπλοκα και δεν είμαι σίγουρος πως μπαίνουν όλες οι παράμετροι στην εξίσωση.

 

Όσον αφορά στην mv, επειδή τόσο η mv όσο και η cp χρησιμοποιούν την ίδια εσωτερική συνάρτηση copy(), η οποία καλεί την copy_internal() που κάνει όλη τη δουλειά, προφανώς η συμπεριφορά είναι η ίδια. Απ' ότι βλέπω στον κώδικα των coreutils δε, υπάρχει κάποια πρόβλεψη για μεταβλητό buffer size, αλλά:

• Έχει minimum buffer size 8 kB
  
• Χρησιμοποιεί κάποιο «optimal» i/o block size που του επιστρέφει η stat() του αρχείου, το οποίο στο σύστημά μου (x86 με SATA δίσκο) είναι 4kB και υποψιάζομαι ότι απλά συμπίπτει με το filesystem block.
  

Πάντως ο ίδιος ο developer αναφέρει μέσα στον κώδικα:

>
       /* These days there's no point ever messing with buffers smaller
          than 8 KiB.  It would be nice to configure SMALL_BUF_SIZE
          dynamically for this host and pair of files, but there doesn't
          seem to be a good way to get readahead info portably.  */
       enum { SMALL_BUF_SIZE = 8 * 1024 };                                                   

 

Θα το διερευνήσω διεξοδικότερα το θέμα μόλις μου έρθει ένα νέο μηχάνημα με RAID-5.

[nske]

Πάντως στο copy μονοκόμματων αρχείων δεν συμβαίνει αυτό το πράγμα (η cp και η rsync αποδίδουν πάνω κάτω το ίδιο). Ίσως η rsync εμφανίζει και κάποια άλλη ιδιαιτερότητα στην αντιγραφή πολλών αρχείων και αυτή είναι που προκαλεί τη διαφορά επιδόσεων του raid0.

 

Αλλά έστω ότι έχουμε ένα αρχείο 150kbytes και 75 αρχεία 2kbytes. Για το raid0 ποια είναι η διαφορά; Και στις δύο περιπτώσεις θα παραλάβει για γράψιμο 4K blocks του filesystem και θα έχει να γράψει τον ίδιο αριθμό blocks και stripes. Οπότε και το filesystem κάπου πρέπει να μπαίνει στην εξίσωση.

[firewalker]

Τα δεδομένα που προέρχονται από πολλά μικρά αρχεία πως γράφονται; Ξέρει το μέσο ότι είναι από πολλά αρχεία; Αν ναι, πως τα τακτοποιεί ώστε να τα ξεχωρίζει (αν χρειάζεται);

 

Σε raid 0 μήπως τα μικρά αρχεία τακτοποιούνται διαφορετικά;

 

Το file system, ξέρει ότι κάθεται σε raid; Το ενδιαφέρει;

[nske]

Αλλά έστω ότι έχουμε ένα αρχείο 150kbytes και 75 αρχεία 2kbytes. Για το raid0 ποια είναι η διαφορά; Και στις δύο περιπτώσεις θα παραλάβει για γράψιμο 4K blocks του filesystem και θα έχει να γράψει τον ίδιο αριθμό blocks και stripes.

Μάλλον βλακείες λέω, αφού ένα αρχείο καταλαμβάνει minimum 1 block στο filesystem, με δεδομένο fs blocksize 4K και raid stripe size 64K, στην πρώτη περίπτωση θα έχουμε 38 blocks των 4kbytes, που θα γραφτούν στο raid device σε 3 stripes και στην δεύτερη 75 blocks των 4kbytes που θα γραφτούν σε 5 stripes.

 

Σε raid 0 μήπως τα μικρά αρχεία τακτοποιούνται διαφορετικά;

Όχι, δεν ξέρει την ένοια του αρχείου.

 

Το file system, ξέρει ότι κάθεται σε raid; Το ενδιαφέρει;

Ούτε αυτό ξέρει και το ενδιαφέρει. Είναι τελείως αυτόνομες τεχνολογίες που μιλάνε με γενικά interfaces, η κοινή τους γλώσσα φθάνει μέχρι την ένοια του "block".

 

Αυτά που βλέπουμε είναι ότι:

 

- Το πρόβλημα εξαρτάται από τη χρήση raid

- Το πρόβλημα εξαρτάται από την εγγραφή μικρών αρχείων και από τον τρόπο με τον οποίο εγγράφονται στο filesystem (από το πρόγραμμα όπως η cp ή η rsync).

 

Αλλά αν ακολουθήσουμε την πορεία των δεδομένων (πώς επηρεάζονται από τα διάφορα υποσυστήματα) από τη στιγμή που θα διαβαστούν μέχρις ότου γραφτούν σε raid stripes, μάλλον θα δούμε οι παράγοντες που εμπλέκονται είναι πάρα πολλοί και πολύπλοκοι.

[firewalker]

Για το file system το βλέπω λογικό να διαχειρίζεται διαφορετικά τα μικρά αρχεία το κάθε πρόγραμμα. Όταν για παράδειγμα η cp γράφει πολλά μικρά αρχεία θα επαναλαμβάνει κάποια πράγματα που για το ένα αρχείο θα γίνετε μόνο μια φορά. Το θέμα είναι γιατί να έχει αντίκτυπο μόνο στο raid 0 (προς το παρόν).