Libata PATA (Parallel ATA) UNIONE:

Con “Parallel ATA” intendiamo tutti gli ATA/IDE controllers e drives che abbiamo usato fino ad oggi prima di SATA. Fin quasi dall’inizio, uno degli obiettivi di alcuni kernel hackers e’ stato quello di rimpiazzare gli IDE drivers disponibili in drivers/ide (Nella configurazione del kernel, tutto sotto “Device drivers -> ATA/ATAPI/MFM/RLL support“) con una reimplementazione dall’alto di libata (ES.: i “SATA layer“).I Drivers/ide soffrono di alcuni oscuri problemi, e re-implementarli in libata e’ stato piu’ facile che risolvere i problemi irrisolvibili dei drivers/ideAlan Cox si e’ preso carico del lavoro (una conseguenza dell’unione sotto PATA e’ che libata e tutti i driver SATA sono stati mossi dai drivers/scsi (disponibili in “Device drivers -> SCSI device support -> SCSI low-level drivers” ) ai drivers/ata (adesso “Device drivers -> Serial ATA (prod) and Parallel ATA (experimental) drivers”), e tutte le opzioni CONFIG_SCSI_FOOBAR per i driver SATA individuali sono stati cambiati in CONFIG_FOOBAR, il che significa che potremmo aver bisogno di riconfigurare le nostre opzioni SATA)

Il kernel 2.6.19 potrebbe avere 2 drivers per i nostri dispositivi PATA-based : Il vecchio IDE driver sotto “Device drivers -> ATA/ATAPI/MFM/RLL support” e un driver alternativo “Device drivers -> Serial ATA (prod) and Parallel ATA (experimental) drivers
Quale scegliere? L’opzione piu’ sicura e’ quella di usare i vecchi driver: I vecchi driver continueranno a funzionare come prima. Non ci sara’ alcun cambiamento adottando questo sistema.

Per continuare in questa interessante lettura, vi rimando al sito principale..da dove proviene questo lembo di spiegazione.

Kernelnewbies.org

Traduco in maniera piu’ “terrena” quello che e’ stato scritto aiutandomi con delle fake-questions:

Ma in sostanza cosa cambia ?

Tutti i dispositivi cdrom, siano essi SCSI o ATA/IDE sono collegati ai dispositivi virtuali

/dev/scd*

Tutti i dispositivi di memoria di massa-usb/flash/SD/MMC/ e altro, sono automaticamente montati da Udev

– Nel file /etc/fstab cosa devo scrivere?

Sostanzialmente nulla.
Kubuntu e Ubuntu hanno i propri demoni per la gestione di Udev. Per quanto riguarda Kubuntu e il kde, tutti i dispositivi sono montati nello stesso punto di mount (/media) con un device assegnato random ma con criterio (hdd=sdb*, sdf*..)
Un classico file /etc/fstab:

# /etc/fstab: static file system information.
#
#
proc /proc proc defaults 0 0
# /dev/sda1
/dev/sda1 / ext3 nouser,defaults,errors=remount-ro,atime,auto,rw,dev,exec,suid 0 0
# /dev/sda5
/dev/sda5 none swap sw 0 0

Come suggerisce il testo in grassetto, fstab si occupa di dispositivi statici, come i filesystem interni)

Che cosa e’ l’UUID?

E’ un codice identificativo a 128bit, piu’ che altro lo vedo come un “palliativo” da parte della Canonical per far fronte a questa ambigua situazione dual-driver. L’uuid e’ facoltativo, e secondo me si puo’ fare benissimo a meno

sudo vol_id -u /dev/sd*

Ma se io inserisco un punto di montaggio, cosa succede?

Niente. Il kernel prende le informazioni da /etc/fstab e cerca di montare il dispositivo secondo le regole ivi contenute.
Tra le conseguenze possiamo avere:

– 2 punti di mount
– niente messaggio dbus di avvenuto collegamento
– necessita’ di mount manuale
– nessun montaggio ne’ automatico ne’ manuale
– montaggio in sola lettura

Dove posso gestire facilmente il mio file /etc/fstab con Kubuntu?

Dal kcontrol–amministrazione di sistema–dischi e filesystem

Inserendo la password per i permessi di root naturalmente.

Coma mi conviene realmente fare?

Personalmente ho tolto dalla configurazione del kernel tutta la parte relativa a ATA/ATAPI(per sicurezza):

L’ho ricompilato avendo l’accortezza, prima di riavviare il sistema, di modificare in /etc/fstab:

+ # /dev/sda1
/dev/sda1 / ext3 nouser,defaults,errors=remount-ro,atime,auto,rw,dev,exec,suid 0 0

# /dev/hda1
/dev/hda1 / ext3 nouser,defaults,errors=remount-ro,atime,auto,rw,dev,exec,suid 0 0

..e in /boot/grub/menu.lst ho fatto lo stesso.

Posso modificare solo fstab e menu.lst senza dover ricompilare il kernel?

Si…tant’e’ vero che ho fatto proprio una prova in questo senso, cioe’ provando ad avviare con un kernel Ubuntu (2.6.20-16). Il risultato e’ stato positivo. Tutti i nuovi dispositivi funzionano esattamente come descritto nella spiegazione ad inizio articolo.

– In kinfocenter pero’ vedo che il dispositivo e’ /dev/sr0. Perche’?

I CD-ROM SCSI usano il numero primario 11.
I numeri secondari sono allocati dinamicamente, dove il primo CD-ROM trovato è ha il numero secondario 0, il secondo l’1 e così via.
La convenzione standard per l’attribuzione dei nomi è:

/dev/sr{numero}, anche se alcune distribuzioni hanno usato /dev/scd{numero}, con esempi quali

/dev/sr0 /dev/scd0
/dev/sr1 /dev/scd1

_____________________

Raccolta faq Libata
Serial ATA for Linux

Related Posts Plugin for WordPress, Blogger...

Il tuo indirizzo ip:
34.238.192.150

Valutazione 3.00 su 5
happy wheels 2 demo

Category:

Senza categoria

Tags:

Commenti via Facebook:

Leave a Reply

Your email address will not be published. Required fields are marked *

*

18 Comments

  • Caste ITALY 12 anni ago

    Queste guide sul kernel le [b]a d o r o[/b]…grazie per quest’altra piccola perla, [b]Divi[/b] 😉

      Quota

  • Caste ITALY 12 anni ago

    Sì, vabbé…magari, se riuscissi ad inserire anche i tag giusti sarebbe meglio (ho messo quelli per BB nel post precedente).

    😀

    P.S. Scusa per il doppio post.

      Quota

  • telperion ITALY 12 anni ago

    Attenzione che usare tutto scsi con Ubuntu con alcuni chipset crea problemi (es il mio Nvidia2) stranamente solo su Ubuntu mentre Sabayon es. funziona perfettamente.
    Perchè? Boh, e tutto sommato chissene,
    io continuo ad usare i sicuri hda hdb hdc hdd anche con il kernel 2.6.22.1
    e tanti saluti.

      Quota

  • Hai detto diverse inesattezze sullo UUID. Non è stato inventato da Canonical e non è decisamente mirato alla “far fronte a questa ambigua situazione dual-driver”. Ovviamente pretendere che uno conosca il Distributed Computing Environment è troppo, ma un giretto su Wikipedia non sarebbe male.

      Quota

  • @Matteo
    io non ho detto che l’ha inventato la Canonical..leggi bene per piacere, ho detto che l’UUID l’ha usato per evitare di assumere una posizione definitiva su ide e sata…visto che alcuni sulla feisty hanno sd* e altri hd*..ovviamente pretendere che qualcuno conosca l’ Educazione…prova a fare un giretto su wikipedia sotto questa voce.
    @Telperion
    prendi ad esempio i cdrom. il problema e’ che adesso molti programmi sono “tarati” su /dev/scd* e non /dev/cdrom..
    Sarebbe opportuno aggiornarsi..ma come sempre sono scelte personali

      Quota

  • H4TtoRy ITALY 12 anni ago

    Ciao divi… se non sbaglio, per non creare confusione nel planet di Ubuntu, è meglio omettere il carattere & qui la discussione del forum

    Scusa per questo piccolo OT

      Quota

  • @H4ttory
    grazie ho corretto
    🙂

      Quota

  • @divilinu: evidentemente ho male interpretato la tua frase ma, di primo acchito, mi da l’idea che Canonical si sia inventata lo UUID per supplire a una situazione non pulita riguardo il naming dei device. Personalmente credo che liquidare l’inclusione dello UUID come metodo risolvere una discrepanza sia riduttivo.

    BTW la mia voleva essere una critica costruttiva, almeno nelle mie intenzioni. Ovviamente non conosco l’educazione perché non l’ho trovata su Wikipedia ma, passami la battuta, tu hai trovato molto facilmente la voce “risposta stizzita”. ;P

      Quota

  • @Matteo
    quando rilevo ironia un po’ troppo spinta io rispondo a modo
    😉
    in piu’ ..io non lo so perche’ la Canonical ha introdotto l’UUID..e’ solo una mia supposizione che puo’ essere sbagliata..su questo non posso metterci la mano sul fuoco..

      Quota

  • @divilinu: l’importante è chiarirsi, no? 🙂

    Riguardo all’introduzione dello UUID in genere è molto di moda perché permette un’identificazione delle partizioni più consistente del solito sistema di naming.

      Quota

  • telperion ITALY 12 anni ago

    No divi
    se metto /dev/sdb1 il sistema non parte,
    e i cd dvd se li tolgo da fstab non vanno.

      Quota

  • l’UUID ha la funzione di distinguere univocamente quella sola partizione/disco.
    c’e’ un pero’: NON, NON, e NON funziona.
    esempio: aggiorno il mio kernel (quelli di serie mi stanno qui lol per vari motivi, troppo pesanti, troppa “rumenta” di cui posso fare a meno, eccetera), faccio il pacchetto deb, per esempio, per comodità, cosi mi porto a spasso il mio kernel su tutti i pc con ubuntu che uso. che succede ? viene aggiornato grub (bella cosa), ubuntu mi ci piazza l’UUID e cosa otteniamo ? un bel kernel panic … niente root … metti /dev/hda2 (e solo un esempio) e che capita ? MAGIA … funziona subito. penso: mi ha sbagliato l’uuid… controllo …. è quello … quindi ? semplice … NON, NON, e NON funziona.
    altro esempio: in fstab ubuntu lavora con l’UUID … adesso .. ditemi voi … guardo fstab e che *caspita* ci devo capire li dentro ?

    UUID=ed7d59c2-44dd-4562-9afa-1bdfb23b5379 / ext3 defaults,errors=remount-ro 0 1 <—- CHE *CAZZO* DI DISCO E’ ?? bah

    /dev/hda2 ext3 defaults,errors=remount-ro 0 1 <—- QUALE DISCO SARA’ ? ora si, ha senso 🙂

    se volete vado avanti ancora. in conclusione: grande schifezza … devono eliminarlo… non serve a un tubo e oltretutto NON funziona 😀

      Quota

  • aggiungo pure questo che mi viene in mente, per la serie “linux for human beings” (se succede allo niubbo ditemi che cosa fa) …
    ESEMPIO: ho una partizione secondaria sul mio hard disk per i dati … UDEV la trova e provvede a popolare FSTAB … e mi ci piazza l’UUID … cosi me la monta al boot … fantastico no ? certo … peccato per una cosuccia: LEVO la partizione perche non mi serve più, mi sta sulle balle, trovatelo voi il motivo … al prossimo BOOT che succede ? il sistema non si avvia … perchè la partizione non c’e’ piu’, e ovviamente UDEV non puo’ intervenire perchè ancora non e avviato… se conosco il problema edito fstab, elimino la riga, e riparto.
    CONTROPROVA: al posto dell’ UUID ci metto /dev/sda3 (per esempio) in fstab, elimino la partizione, riavvio il sistema, e altra MAGIA 😀 il sistema parte …

    IMHO Canonical ha fatto una gran *cazzata* poteva benissimo funzionare TUTTO senza quel COSO. scusa il doppio post Divi 🙂

      Quota

  • @telperion
    non sdb1..ma sda1
    e’ davvero strano che se togli i cdrom non funzionano..comunque sono due diversi assetti che e’ giusto tenere separati, finche’ si puo’.
    @Luna
    e’ vero che viene “piazzato” l’uuid nel menu.lst..ma e’ vero anche che non c’e’ alcun problema di boot. Io stesso ho un mix UUID in menu.lst e device in /etc/fstab..ma linux boota lo stesso..

      Quota

  • telperion ITALY 12 anni ago

    @divi su sda1 io ho win.
    Le partizioni Linux sono su (hdb) sdb2-3-6-7-8-10-12-14-16

      Quota

  • @divi: si lo so che boota … ma mica sempre … se l’ho scritto è perche a me e successo, e non solo una volta. comunque, ciò non toglie che UUID è un accrocchio inutile e confusionario 😉

      Quota

  • @telperion, divilinu: anche io se li levo da fstab non mi funzionano + .. difatti li tolsi credendo che fossero “in piu” per semplificarmi fstab, visto che una montagna di partizioni e di dischi già e complicato di suo, ma la cosa ha effetto negativo .. niente fstab .. niente ciddi’ e dividdi’ 🙂

      Quota