Τι είναι το USB syncing?

Giannis Papadopoulos ipapadop at inf.uth.gr
Tue Mar 21 00:56:10 EET 2006


Pistiolis Konstantinos wrote:
>>> δηλαδή, ν'ανοιγοκλείνω συνεχώς το αρχείο σε append mode.
>>> Πράγμα που το έχω κάνει άπειρες φορές και σε linux και σε IRIX, και
>>> δουλεύει
>>> τέλεια και ταχύτατα, ακόμα κι αν ταυτόχρονα κάποιος διαβάζει το ίδιο
>>> αρχείο.
>>> (ναι, το έχω χρησιμοποιήσει και ως pipe για debuging λόγους)
>>
>>
>> Φυσικά ξέρεις ότι μάλλον δεν θα έπρεπε να το κάνεις έτσι, είτε επειδή
>> βαριέσαι είτε για οποιονδήποτε άλλο λόγο.
> 
> Δε μιλάμε για κώδικα. Θέλω να τρέξω το προγραμμα(προγραμματάκι) μια
> φορά για να δώ τι βγάζει. Και μετά σβήνεται.
> Τώρα κατά την εκτέλεση, αν το σύστημα αποφασίσει να κάνει sync
> και 2-3 φορές κατά τη διάρκεια των 30 ολόκληρων msec τι πειράζει;
> Μόνο το caching του file επηρρεάζει, λίγο παραπάνω χρόνο συστήματος και
> ίσως χαλάει κάπως την ενημέρωση του journaling.

Δεν νομίζω να χαλάει κάτι. Απλώς είναι inefficient και κατά 99.9% 
υπάρχει σε κάθε περίπτωση και άλλος τρόπος από άνοιγμα-κλείσιμο αρχείου 
σε κάθε loop.

> Νομίζω άλλωστε ότι το fclose δεν προκαλεί και sync άμεσα, εκτός κι
> αν τερματίσει το πρόγραμμά σου. Πρακτικά, ίσως να μην έχουν κάν γραφτεί
> δεδομένα στο δίσκο (εκτός ίσως από το entry για το αρχείο) μέχρι τη
> λήξη του προγράμματος, αν δεν ξεπερνιέται το μέγεθος του block.

Και να τερματίσει, πάλι δεν ξέρω αν γίνεται enforce το sync. Και όντως η 
fclose() εγγυάται μόνον το flush των userspace buffers που προσφέρει η C 
lib.

> Υπάρχει περίπτωση να γίνει κάτι κακό έτσι;

Όχι, αλλά σε κάτι που είναι documented μόνον για όσους δουλεύουν πάνω 
στο windows, μόνον εικασίες μπορούμε να κάνουμε.

Κακό δεν θα κάνει, αλλά σίγουρα καθυστερεί - και που από μόνο του είναι 
και αυτό κακό.

>>> Το πρόγραμα έτρεχε σε M$win. Φαντάζεστε τι έγινε;
>>> Για να διαβάσει ένα bitmap 32x240 pixels ήθελε 2~4 λεπτά σε P2.4GHz και
>>> με  το
>>> αρχείο στο σκληρό δίσκοοοοοοοο........
>>> Εν έτει 2006, λές και υπάρχει πιθανότητα κάποιος να «βγάλει» το σκληρό
>>> δίσκο!...
>>> Αφού δεν το πίστευα και χρειάστηκα 25 λεπτά παρακολούθηση με το debugger
>>> για να βεβαιωθώ ότι δεν απειρολουπάρει κάπου!
>>
>>
>> Ένα κακογραμμένο κομμάτι κώδικα δεν αποτελεί απόδειξη ότι η τάδε
>> πλατφόρμα είναι καλύτερη από την άλλη. Αν από την άλλη είχες κάποιο
>> σύστημα που έπρεπε να διαχειρίζεται 100 αρχεία/sec τότε το ξανασυζητάμε,
>> και ναι, το Windows πάσχει σε αυτόν τον τομέα.
>>
> φυσικά, αφού δεν θα μπορεί να κάνει caching όλα τα αρχεία ταυτόχρονα, και
> θέλει και μπόλικο χρόνο συστήματος για να διαχειριστεί τόσες κλήσεις  
> συστήματος.

Μπορώ να σκεφτώ κανά δυο εφαρμογές, αλλά τέσπα. Λες και το WinFS να είχε 
πρόβλημα με αυτό που αναφέρεις;

> Αλλά αν ο ρυθμός εγγραφής είναι χαμηλός και τα δεδομένα
> λιγότερα από το block του συστήματος αρχείων τρώγεται, ενώ αν γράφεις
> γρήγορα τότε κι ένα αρχείο να έχεις και νάναι και μόνιμα ανοιχτο κλάφτα.
> 
> 
> Κώστας

Που να δεις και στο διάβασμα τι γίνεται (επειδή είχα πρόσφατη πίκρα). 
Άστα χάλια.



More information about the Linux-greek-users mailing list