Defragmentáció (Töredezettségmentesítés)

Kezdőlap Fórumok Adattárolók problémái Defragmentáció (Töredezettségmentesítés)

10 bejegyzés megtekintése - 21-30 / 35
  • Szerző
    Bejegyzés
  • #2140524
    pointux
    Felhasználó

      „Igen felesleges, ez az általános elmélet de pl.aki videovágásra használja a linuxot több gigát töröl?+tömörit programokat intenziven használja a merevlemezét?Valami ür csak keletkezik a merevlemezén azzal hogy tud elboldogulni a fájrendszer,legyenaz ext3 vagy más?”
      Nem a nagy file-októl töredezik a file-rendszer, hanem a kis file-októl.

      Nézzük, hogy hogyan is történik ez:
      Adott egy 10 M file helyet foglalunk neki egy 512 M szektorban. Adott egy másik 15 M file, helyet foglalunk a következő 512 M szektorban. (Máris ott a lyuk… arányaiban nagy lyuk. 502 M lyuk 25 M hasznos terület.)
      Van egy 1500 M file lefoglalunk 3 db 512 M szektort, majd egy ugyanilyen file-lel megismételjük. ( 36M lyuk 3000 M adat.)

      Mit is tehetünk?
      Mondhatnánk azt, hogy mi sem egyszerűbb, folytatni kell az előző szektort. Igenám, könnyű ezt mondani, de a megvalósításhoz az kell, hogy az adott szektor épp „nyitva” legyen, mivel az elérés sok időt vesz igénybe. Egy szinkronizált adatkiírásnál ez ésszerű sebességgel nem valósítható meg. (Megkeresni egy használt szektort, megnyitni, megkeresni benne az adatok, folytatni…) És még ott egy másik probléma: mi van, ha a szektorunk betelik és a felét egy másik szektorban kell tárolni. (Nos ekkor egy file eléréséhez, még két szektort is meg kell nyitni.)

      Ésszerű megoldás a nem szinkronizált írás, amit a unix alapú rendszerek használnak (már régóta). Előre lefoglaljuk a helyet, és az adatot mindaddig a memóriában tartjuk, amíg tényleg ki nem kell írni. Mi történik? A módosításokhoz csupán memória allokáció és hozzáférés szükséges, nem a jóval kisebb sebességű háttértárolóé. Ha végeztünk kiírjuk a lemezre. Ha már nem fér el az adott helyen, akkor a lemezen lefoglalunk egy másik helyet és oda írjuk végül is ki. (Igen, bizony ez az a sync, umount… dolog, ami miatt utálják a windózhoz szokottak a renccert… ez az ami miatt nem lehet csak úgy kirángatni a floppy-t…)

      Mi történik, ha a lemezen nincs hely újabb szektor létrehozására és a lyukakat kell használni?
      (Ez az a bizonyos 80%-osként emlegetett szabály. Persze amint megvilágítottam a nagy file-ok esetén ez lehet 90 % fölött is.) Ekkor baj van., ugyanis a következő adatot már tördelni kell. És az ezt követő új file-ok egy része, illetve a régi növekedő file-ok egy része töredezik.
      Na ekkor nem árt egy töredezettség-mentesítés… na, de hogyan? Sehogy. Nincs mód rá, hisz nincs hely. Nincs ideiglenes hely, ahol elhelyezze az ember az adatokat. Így szükség van egy másik meghajtóra.

      Van még egy trükk, amit, ha jól tudom a hsf+ használ. A kis file-okat egy helyre gyűjti. Ezáltal a sok kis lyuk egy helyre koncentrálódik, ami még akkor is növeli az elérési sebességet ha már „mindennek vége”.

      A file-másolás mért töredezettségmentesít automatikusan? (Feltéve, ha van hely, ezt megtennie.)
      Tegyük fel, hogy van 2 egymástól távoli szektorban adatunk. Ezt ugye borzalmas kezelni. Viszont a rendszer ismeri a méretét és amikor másolunk az új adatnak már egymáshoz közel fogja lefoglalni a helyet (lehetőleg minél kevesebb szektorban). Az új adatok a régivel szemben így már nem lesznek töredezettek. (Az azonos partíción lévő mozgatás NEM ez a kategória, mert a az optimalizálás érdekében csak a metaadatok (mondjuk így) módosulnak!)

      Remélem, most már sikerült megértetni, hogy egyes helyeken miért elfogadhatatlan, más helyeken, pedig miért elenyésző mértékű a töredezettség (amivel foglalkozni sem érdemes). És remélem, most már az is világos, hogy miért töredezettlenít a másolás.

      #2140525
      pointux
      Felhasználó

        „Igen felesleges, ez az általános elmélet de pl.aki videovágásra használja a linuxot több gigát töröl?+tömörit programokat intenziven használja a merevlemezét?Valami ür csak keletkezik a merevlemezén azzal hogy tud elboldogulni a fájrendszer,legyenaz ext3 vagy más?”
        Nem a nagy file-októl töredezik a file-rendszer, hanem a kis file-októl.

        Nézzük, hogy hogyan is történik ez:
        Adott egy 10 M file helyet foglalunk neki egy 512 M szektorban. Adott egy másik 15 M file, helyet foglalunk a következő 512 M szektorban. (Máris ott a lyuk… arányaiban nagy lyuk. 502 M lyuk 25 M hasznos terület.)
        Van egy 1500 M file lefoglalunk 3 db 512 M szektort, majd egy ugyanilyen file-lel megismételjük. ( 36M lyuk 3000 M adat.)

        Mit is tehetünk?
        Mondhatnánk azt, hogy mi sem egyszerűbb, folytatni kell az előző szektort. Igenám, könnyű ezt mondani, de a megvalósításhoz az kell, hogy az adott szektor épp „nyitva” legyen, mivel az elérés sok időt vesz igénybe. Egy szinkronizált adatkiírásnál ez ésszerű sebességgel nem valósítható meg. (Megkeresni egy használt szektort, megnyitni, megkeresni benne az adatok, folytatni…) És még ott egy másik probléma: mi van, ha a szektorunk betelik és a felét egy másik szektorban kell tárolni. (Nos ekkor egy file eléréséhez, még két szektort is meg kell nyitni.)

        Ésszerű megoldás a nem szinkronizált írás, amit a unix alapú rendszerek használnak (már régóta). Előre lefoglaljuk a helyet, és az adatot mindaddig a memóriában tartjuk, amíg tényleg ki nem kell írni. Mi történik? A módosításokhoz csupán memória allokáció és hozzáférés szükséges, nem a jóval kisebb sebességű háttértárolóé. Ha végeztünk kiírjuk a lemezre. Ha már nem fér el az adott helyen, akkor a lemezen lefoglalunk egy másik helyet és oda írjuk végül is ki. (Igen, bizony ez az a sync, umount… dolog, ami miatt utálják a windózhoz szokottak a renccert… ez az ami miatt nem lehet csak úgy kirángatni a floppy-t…)

        Mi történik, ha a lemezen nincs hely újabb szektor létrehozására és a lyukakat kell használni?
        (Ez az a bizonyos 80%-osként emlegetett szabály. Persze amint megvilágítottam a nagy file-ok esetén ez lehet 90 % fölött is.) Ekkor baj van., ugyanis a következő adatot már tördelni kell. És az ezt követő új file-ok egy része, illetve a régi növekedő file-ok egy része töredezik.
        Na ekkor nem árt egy töredezettség-mentesítés… na, de hogyan? Sehogy. Nincs mód rá, hisz nincs hely. Nincs ideiglenes hely, ahol elhelyezze az ember az adatokat. Így szükség van egy másik meghajtóra.

        Van még egy trükk, amit, ha jól tudom a hsf+ használ. A kis file-okat egy helyre gyűjti. Ezáltal a sok kis lyuk egy helyre koncentrálódik, ami még akkor is növeli az elérési sebességet ha már „mindennek vége”.

        A file-másolás mért töredezettségmentesít automatikusan? (Feltéve, ha van hely, ezt megtennie.)
        Tegyük fel, hogy van 2 egymástól távoli szektorban adatunk. Ezt ugye borzalmas kezelni. Viszont a rendszer ismeri a méretét és amikor másolunk az új adatnak már egymáshoz közel fogja lefoglalni a helyet (lehetőleg minél kevesebb szektorban). Az új adatok a régivel szemben így már nem lesznek töredezettek. (Az azonos partíción lévő mozgatás NEM ez a kategória, mert a az optimalizálás érdekében csak a metaadatok (mondjuk így) módosulnak!)

        Remélem, most már sikerült megértetni, hogy egyes helyeken miért elfogadhatatlan, más helyeken, pedig miért elenyésző mértékű a töredezettség (amivel foglalkozni sem érdemes). És remélem, most már az is világos, hogy miért töredezettlenít a másolás.

        #2140526
        Vladi
        Felhasználó

          vizsla tanár úr!

          Hálás köszönet az előadásért. Eddig én csak tudtam, hogy nem töredezik, mostmár értem is, hogy miért nem. 4.gif

          Egy kérdésem azért maradt:

          vizsla wrote:
          Mi történik, ha a lemezen nincs hely újabb szektor létrehozására és a lyukakat kell használni?
          (Ez az a bizonyos 80%-osként emlegetett szabály. Persze amint megvilágítottam a nagy file-ok esetén ez lehet 90 % fölött is.) Ekkor baj van., ugyanis a következő adatot már tördelni kell. És az ezt követő új file-ok egy része, illetve a régi növekedő file-ok egy része töredezik.
          Na ekkor nem árt egy töredezettség-mentesítés… na, de hogyan? Sehogy. Nincs mód rá, hisz nincs hely. Nincs ideiglenes hely, ahol elhelyezze az ember az adatokat. Így szükség van egy másik meghajtóra.

          Mi van akkor, ha elértem – vagy át is léptem – a 90% határt? Persze töredezett lesz. Nade mi van akkor, ha törlök – teszem azt a nem töredezettből – annyi adatot, hogy megint csak 60%-ot foglalok? Akkor „összepakolja” magának a töredezett fájlokat, vagy mi történik?

          #2140527
          Vladi
          Felhasználó

            vizsla tanár úr!

            Hálás köszönet az előadásért. Eddig én csak tudtam, hogy nem töredezik, mostmár értem is, hogy miért nem. 4.gif

            Egy kérdésem azért maradt:

            vizsla wrote:
            Mi történik, ha a lemezen nincs hely újabb szektor létrehozására és a lyukakat kell használni?
            (Ez az a bizonyos 80%-osként emlegetett szabály. Persze amint megvilágítottam a nagy file-ok esetén ez lehet 90 % fölött is.) Ekkor baj van., ugyanis a következő adatot már tördelni kell. És az ezt követő új file-ok egy része, illetve a régi növekedő file-ok egy része töredezik.
            Na ekkor nem árt egy töredezettség-mentesítés… na, de hogyan? Sehogy. Nincs mód rá, hisz nincs hely. Nincs ideiglenes hely, ahol elhelyezze az ember az adatokat. Így szükség van egy másik meghajtóra.

            Mi van akkor, ha elértem – vagy át is léptem – a 90% határt? Persze töredezett lesz. Nade mi van akkor, ha törlök – teszem azt a nem töredezettből – annyi adatot, hogy megint csak 60%-ot foglalok? Akkor „összepakolja” magának a töredezett fájlokat, vagy mi történik?

            #2140528
            ates71
            Felhasználó

              Egyszerübben megfogalmazva a windows igyekszik a fájlokat ugy erendezni hogy minnél közelebb legyen a merevlemez elejéhez sorba rakni ami azt eredményezi hogy ha növekszik a fájlok mérete nemarad hely.Nem tud hova nyujtozkodni.A linux viszont ugymond szétszorja a fájlokat a merevlemzen nem igyekszik rögtön mindent elöre pakolni,ebböl kifolyolag a megmaradt üres helyeket munka közben szépen kiegyenesiti mivel van hová nyujtozkodnia.

              #2140529
              ates71
              Felhasználó

                Egyszerübben megfogalmazva a windows igyekszik a fájlokat ugy erendezni hogy minnél közelebb legyen a merevlemez elejéhez sorba rakni ami azt eredményezi hogy ha növekszik a fájlok mérete nemarad hely.Nem tud hova nyujtozkodni.A linux viszont ugymond szétszorja a fájlokat a merevlemzen nem igyekszik rögtön mindent elöre pakolni,ebböl kifolyolag a megmaradt üres helyeket munka közben szépen kiegyenesiti mivel van hová nyujtozkodnia.

                #2140530
                pointux
                Felhasználó

                  „Mi van akkor, ha elértem – vagy át is léptem – a 90% határt? Persze töredezett lesz. Nade mi van akkor, ha törlök – teszem azt a nem töredezettből – annyi adatot, hogy megint csak 60%-ot foglalok? Akkor „összepakolja” magának a töredezett fájlokat, vagy mi történik?”
                  Ha ügyes vagy, akkor a töredezett file-okat fogod törölni. :))))
                  Ha törlöd a file-okat, az nem befolyásolja az eredeti file-ok helyzetét. (Kivéve, ha olyan file-rendszered van, ami naplózza az éppen nem kívánatos adathalmazokat. És ezt a rendszer közben rendezi. Ez utóbbit ugye ilyenkor észrevennéd. 🙂 Pont ezért nem hatékony az a file-rendszer, ami töredezik.)
                  Persze előfordulhat, hogy használat közben csökken a töredezettség.

                  Aki pedig maximalista és le akarja a file-rendszerének mondjuk megdöbbentően magas 5-6 %-os  töredezettségét 1-2 %-ra, arra is van megoldás. Con csinált erre egy kis scriptet unalmában. 🙂

                  #2140531
                  pointux
                  Felhasználó

                    „Mi van akkor, ha elértem – vagy át is léptem – a 90% határt? Persze töredezett lesz. Nade mi van akkor, ha törlök – teszem azt a nem töredezettből – annyi adatot, hogy megint csak 60%-ot foglalok? Akkor „összepakolja” magának a töredezett fájlokat, vagy mi történik?”
                    Ha ügyes vagy, akkor a töredezett file-okat fogod törölni. :))))
                    Ha törlöd a file-okat, az nem befolyásolja az eredeti file-ok helyzetét. (Kivéve, ha olyan file-rendszered van, ami naplózza az éppen nem kívánatos adathalmazokat. És ezt a rendszer közben rendezi. Ez utóbbit ugye ilyenkor észrevennéd. 🙂 Pont ezért nem hatékony az a file-rendszer, ami töredezik.)
                    Persze előfordulhat, hogy használat közben csökken a töredezettség.

                    Aki pedig maximalista és le akarja a file-rendszerének mondjuk megdöbbentően magas 5-6 %-os  töredezettségét 1-2 %-ra, arra is van megoldás. Con csinált erre egy kis scriptet unalmában. 🙂

                    #2140532
                    Vladi
                    Felhasználó
                      vizsla wrote:
                      (Kivéve, ha olyan file-rendszered van, ami naplózza az éppen nem kívánatos adathalmazokat. És ezt a rendszer közben rendezi. Ez utóbbit ugye ilyenkor észrevennéd. 🙂

                      Hmmm….
                      Az ext3 naplózó. Akkor ez elvileg elrendezi, ha akad végre elég hely?
                      Jah és miből venném észre? rolleyes.gif

                      #2140533
                      Vladi
                      Felhasználó
                        vizsla wrote:
                        (Kivéve, ha olyan file-rendszered van, ami naplózza az éppen nem kívánatos adathalmazokat. És ezt a rendszer közben rendezi. Ez utóbbit ugye ilyenkor észrevennéd. 🙂

                        Hmmm….
                        Az ext3 naplózó. Akkor ez elvileg elrendezi, ha akad végre elég hely?
                        Jah és miből venném észre? rolleyes.gif

                      10 bejegyzés megtekintése - 21-30 / 35
                      • Be kell jelentkezni a hozzászóláshoz.