ΠΡΟΒΛΗΜΑ στο superblock ενός ufs partition (bsd)

[NullScan]

Καλό μεσημέρι σε όλους. Άντε επιστρέφω στη δουλειά μου...

[carpe_diem_rj]

Παιδια σας ευχαριστω για την τρομερη βοηθεια σας!!! Δεν θα μπορουσα να τα κανω μονος μου μιας και δεν ξερω.... Πως εχετε αποκτησει τετοιες γνωσεις πανω σ αυτα ειναι η δουλεια σας η χομπυ? Ο nske πρεπει να ειναι ο guru απ οτι βλεπω... θα σας αφησω τωρα οταν τελιωσει θα φυγω γιατι εχω δουλεια..αν χρειαστω κατι αλλα θα σας ενοχλισω παλι μετα τις 7....

[gtroza]

Ο nske πρεπει να ειναι ο guru απ οτι βλεπω...

 

ο NullScan είναι "μαθητευόμενος"

 

σκέψου και να μάθει

 

θα δίνει λύση πρίν το πρόβλημα !

 

 

ευχαριστώ τον guru nske για τον χώρο !

γειά σου fire

NullScan, ελπίζω να το "έσωσα" !

 

.

[NullScan]

Χαχαχα δέν έχω τέτοια προβλήματα και το ξέρετε όσοι με ξέρετε,

Καλύτερα μιά ζωή μαθητευόμενος ;-)

[nske]

Τώρα που το σκέφτομαι, δεν είμαι σίγουρος πόση συμπίεση έχει περιθώριο να κάνει η gzip με τόσο μικρό block size όσο είπα στην αρχή (8192 bytes). Έχω την εντύπωση ότι θα πετύχαινε καλύτερη συμπίεση αν έβαζες ας πούμε bs=512MB στην dd. Εκτός αν δεν επεξεργάζεται αυτοτελώς το κάθε block, δεν είμαι σίγουρος.

 

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

[firewalker]

ο Nullscan κατά κανόνα ξέρει καλύτερα και αναλυτικότερα από μένα πώς δουλεύει οτιδήποτε, απλά δυστυχώς δεν έχει τόσο χρόνο να γράφει.

 

O Nullscan έχει να ασχολείται με «strange noise» άλλων συστημάτων! Έλα, μην βαράς... :p:p

 

Γεια σου nske!

[NullScan]

Εντάξει, τώρα το χοντρένετε και οι 2

[parsifal]

Τώρα που το σκέφτομαι, δεν είμαι σίγουρος πόση συμπίεση έχει περιθώριο να κάνει η gzip με τόσο μικρό block size όσο είπα στην αρχή (8192 bytes). Έχω την εντύπωση ότι θα πετύχαινε καλύτερη συμπίεση αν έβαζες ας πούμε bs=512MB στην dd. Εκτός αν δεν επεξεργάζεται αυτοτελώς το κάθε block, δεν είμαι σίγουρος.

 

Το block size αφορά μόνο σε τί chunks θα γίνει η ανάγνωση από τη συσκευή (και μπορεί να επηρεάσει την ταχύτητα σε φυσικό επίπεδο, ειδικά τώρα με τα νεότερα μοντέλα σκληρών δίσκων που θα χρησιμοποιούν εγγενώς sectors των 4 Kbytes αντί 512 bytes). Στο άλλο άκρο του pipe η gzip λαμβάνει ένα ενιαίο stream δεδομένων, δεν χαμπαρίζει από blocks και τέτοια...

[nske]

Το block size αφορά μόνο σε τί chunks θα γίνει η ανάγνωση από τη συσκευή (και μπορεί να επηρεάσει την ταχύτητα σε φυσικό επίπεδο, π.χ. τώρα με τα νεότερα μοντέλα σκληρών δίσκων που θα χρησιμοποιούν εγγενώς 512 byte blocks). Στο άλλο άκρο του pipe η gzip λαμβάνει ένα ενιαίο stream δεδομένων, δεν χαμπαρίζει από blocks και τέτοια...

 

Αφορά και σε τι chunks θα γίνει η εγγραφή (υπάρχει η ibs για input και η obs για output, η bs ορίζει και τα δύο μαζί), αλλά έχεις δίκιο, η gzip στο άλλο άκρο του pipe αγνοεί ότι τα δεδομένα γράφονται chunk-chunk, κακώς μπερδεύτηκα.

 

Βέβαια για να γίνεται η συμπίεση σε -ας πούμε- πραγματικό χρόνο, αναγκαστικά πρέπει τα δεδομένα να χωρίζονται σε blocks, -αλλιώς θα έπρεπε να τελειώσει το stream για να ξεκινήσει η συμπίεση-, όμως προφανώς αυτά είναι blocks που κόβει ανεξάρτητα.

 

Ευχαριστώ για το ξεμπέρδεμα

[parsifal]

Αφορά και σε τι chunks θα γίνει η εγγραφή (υπάρχει η ibs για input και η obs για output, η bs ορίζει και τα δύο μαζί), αλλά έχεις δίκιο, η gzip στο άλλο άκρο του pipe αγνοεί ότι τα δεδομένα γράφονται chunk-chunk, κακώς μπερδεύτηκα.

 

nske, νομίζω πως δεν πραγματοποιείται ενδιάμεση εγγραφή σε προσωρινό αρχείο του δίσκου κατά το piping, οπότε «σπάσιμο» του bs switch σε ibs και obs δεν έχει νόημα γιατί δε θα επηρεάσει πρακτικά την ταχύτητα. Αν το λες απλώς ενημερωτικά ότι υπάρχει ως δυνατότητα στη dd, δεκτόν.

 

 

Και σχετικά με κάτι άλλο που ανέφερε ο NullScan πιο πάνω:

Αν ο δίσκος δεν είναι 100% γεμάτος χρησιμοποίησε το pipe σε gzip όπως σου είπε ο nske πιο πάνω, θα σου μειώσει το output file αρκετά, δηλαδή σίγουρα θα σου αφαιρέσει από το τελικό backup τον χώρο που είναι κενός.

 

Η dd διαβάζει οτιδήποτε υπάρχει στη συσκευή, όχι μόνο τα blocks της συσκευής που είναι εν χρήσει από το filesystem, γιατί δουλεύει σε επίπεδο χαμηλότερο από αυτό και δεν έχει γνώση περί filesystem. Μόνο αν είχε προνοήσει ο topic starter να κάνει zero-fill τον κενό χώρο (σιγά να μην... ) θα έβλεπε προς το τέλος του δίσκου (ή ενδιάμεσα, όπου υπάρχει «κενός» χώρος) σημαντικό έως και θεαματικό κέρδος από τη συμπίεση.

[carpe_diem_rj]

Επομενως που καταληγουμε ..ο σκληρος δεν ειναι γεματος.....

Δεν ξερω αρχισε η εγραφη το μεσημερι και ειχα δουλεια οποτε το αφησα και εφυγα οταν γυρισα μετα απο 4 ωρες βρικα τον υπολογιστη κλιστο...δεν ξερω τι εγινε...Μπικα και ειδα οτι το μεγεθος του αρχειου ηταν 70 γιγα μονο ...Νομιζω ειχα παλλα περισσοτερα μεσα.

 

Να αλλαξω το 8192 σε 512 ?

 

Τωρα το εχω ξαναβαλει να κανει παλι backup και θα ειμαι παρον σε ολη την διαρκεια να δω αν θα ειναι παλι ιδιο το μεγεθος...

[nske]

nske, νομίζω πως δεν πραγματοποιείται ενδιάμεση εγγραφή σε προσωρινό αρχείο του δίσκου κατά το piping, οπότε «σπάσιμο» του bs switch σε ibs και obs δεν έχει νόημα γιατί δε θα επηρεάσει πρακτικά την ταχύτητα. Αν το λες απλώς ενημερωτικά ότι υπάρχει ως δυνατότητα στη dd, δεκτόν.

Δεν πραγματοποιείται ενδιάμεση εγγραφή σε προσωρινό αρχείο, απλά είχα στο μυαλό μου ότι τα δεδομένα γράφονται στο stdout, από όπου γίνονται pipe, ανά block, όπως θα γράφονταν σε ένα αρχείο που θα οριζόταν με την -of, και γι' αυτό θα είχε εφαρμογή το obs.

 

Και σχετικά με κάτι άλλο που ανέφερε ο NullScan πιο πάνω:

 

Η dd διαβάζει οτιδήποτε υπάρχει στη συσκευή, όχι μόνο τα blocks της συσκευής που είναι εν χρήσει από το filesystem, γιατί δουλεύει σε επίπεδο χαμηλότερο από αυτό και δεν έχει γνώση περί filesystem..

 

Έχεις απόλυτο δίκιο.

 

Να αλλαξω το 8192 σε 512 ?

Όχι, κατά 99.9% ισχύουν αυτά που είπε ο Parsifal.

 

(αν το έκανες όμως θα έβαζες "512ΜΒ", γιατί διαφορετικά θα θεωρούταν ως μονάδα το byte)

 

Μήπως υπερθερμάνθηκε ο επεξεργαστής και γι' αυτό έκλεισε το pc;

 

Φεύγω από τη δουλειά, θα μπω σε 1 ώρα.

[parsifal]

Ρίχνοντας το επίπεδο συμπίεσης της gzip από -9 σε χαμηλότερο, θα τελειώσει πιο γρήγορα η διαδικασία και με λιγότερη καταπόνηση του επεξεργαστή. -6 είναι το default της gzip, δοκίμασε κι ένα ή δύο κλικ παρακάτω αν θες.

 

Αν όμως υπάρχει πρόβλημα σε hardware επίπεδο και όχι απλά σε filesystem (με το πρώτο να προκαλεί το δεύτερο), είναι πιθανόν η διαδικασία να παίρνει πολλή ώρα λόγω retries κατά την ανάγνωση. Αν μάλιστα υπάρχουν bad sectors, ίσως είναι καλύτερο να χρησιμοποιήσεις την dd_rescue αντί της απλής dd. Περισσότερα εδώ:

http://www.garloff.de/kurt/linux/ddrescue/

http://wiki.linuxquestions.org/wiki/Dd_rescue

[carpe_diem_rj]

Ρίχνοντας το επίπεδο συμπίεσης της gzip από -9 σε χαμηλότερο, θα τελειώσει πιο γρήγορα η διαδικασία και με λιγότερη καταπόνηση του επεξεργαστή. -6 είναι το default της gzip, δοκίμασε κι ένα ή δύο κλικ παρακάτω αν θες.

 

Αν όμως υπάρχει πρόβλημα σε hardware επίπεδο και όχι απλά σε filesystem (με το πρώτο να προκαλεί το δεύτερο), είναι πιθανόν η διαδικασία να παίρνει πολλή ώρα λόγω retries κατά την ανάγνωση. Αν μάλιστα υπάρχουν bad sectors, ίσως είναι καλύτερο να χρησιμοποιήσεις την dd_rescue αντί της απλής dd. Περισσότερα εδώ:

http://www.garloff.de/kurt/linux/ddrescue/

http://wiki.linuxquestions.org/wiki/Dd_rescue

 

Μαλλον θα το βαλω στο -11 γιατι μου το εκανε παλι τωρα...μαλλον απο υπερθερμανση...η cpu ειναι συνεχως στο 100%

 

Οταν κανει reboot γινοτε αυτοματα ολοι οι HD umount ? Γιατι τωρα που ξαναμπικα δεν ειναι mount o σκληρος...

 

Φιλε μου οπτι μου πειτε εσεις θα κανω καθως δεν κατεχω τπτ απο ολα αυτα διστυχως φυσικα....αρα ακουω και κανω οτι μου λετε....

[firewalker]

Αν στο κάνει από υπερθέρμανση υπάρχει κάποιο πρόβλημα με την ψύξη γενικά. Δεν θα έπρεπε 100% cpu usage να στο κάνει αυτό. Δοκίμασε να κολλήσεις την cpu στο 100% χωρίς disk usage. Αναφέρεις κάπου τι σύστημα είναι;