Τι είναι το 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