Tässä läppärissä on kaksi "levyä", C: ja D:
Onko D siis ihan oma erillinen muistinsa, vai onko se vain Ceen toinen puolisko?
Voiko tälle Deelle asentaa käyttöjärjestelmän ilman että se häiritsisi Windowsia joka pyörii Ceellä? D on siis tyhjä.
Lisäys: D on muuten ihmeellisesti n. 120 gigatavua suurempi kuin C
lare290 kirjoitti:
Tässä läppärissä on kaksi "levyä", C: ja D:
Onko D siis ihan oma erillinen muistinsa, vai onko se vain Ceen toinen puolisko?
Voiko tälle Deelle asentaa käyttöjärjestelmän ilman että se häiritsisi Windowsia joka pyörii Ceellä? D on siis tyhjä.Lisäys: D on muuten ihmeellisesti n. 120 gigatavua suurempi kuin C
Riippuu aina läppäristä, onko kaksi vai yksi levyä, joka on jaettu kahteen osaan.
Ja kyllä voi asentaa ilman että häiritsee C:tä, mutta jos haluat vaihtaa toiseen käyttikseen, joudut aina boottaamaan.
Ei ole ihmeellistä, että D: On suurempi. mm. Omassa läppärissäni oli vakiona 200GB Windowsille ja 2TB muutenvaan.
Tavallisesti kuluttajille myytävissä kannettavissa tietokoneissa on vain yksi fyysinen kiintolevy.
Voit asentaa toiselle osiolle (”D-asemalle”) Linuxin, mutta koska Linuxin asennus vaatii käytännössä eri tiedostojärjestelmän kuin Windows, osiota ei voi sen jälkeen käyttää Windowsista. Jos aiot käyttää enimmäkseen Windowsia, on ehkä parempi ensiksi pienentää Windowsista tuota toista osiota (googleta) ja asentaa Linux sitten käyttämättömäksi jääneelle osalle levystä.
Windows:ssa tulee mukana ohjelma "Levynhallinta". Sen voit kirjoittaa kätevästi käynnistä-valikkoon, ja ohjelmasta näkee mitkä asemat kuuluu mille fyysiselle levylle. Sitä kautta onnistuu myös uudelleenosiointi.
Itse olen osioinut kaikki uudet levyni useammaksi levyksi sen jälkeen, kun erään projektin testin yhteydessä ohjelmistovirheeni täytti C-levyn totaalisesti. Levy tuli niin täyteen, ettei järjestelmää saanut alas eikä se väkisin kaatamisen jälkeen käynnistynyt uudelleen. Tämä sattui noin vuonna 1990.
Linuxiahan ei voi bootata NTFS:stä, mutta se osaa muuten käyttää NTFS:ää. Eli juuri kuten Metobolix sanoi, pienentää C-asemaa ja laittaa vapautuneeseen tilaan Linuxin. Jos harrastaa / tekee ohjelmistokehitystä, niin suosittelen omaa tapaani irrottaa kehitysympäristö muusta koneen käytöstä. Tämä tarkoittaa nykyisen D-levyn jakamista kahdeksi osioksi.
Aaro55 kirjoitti:
Itse olen osioinut kaikki uudet levyni useammaksi levyksi sen jälkeen, kun erään projektin testin yhteydessä ohjelmistovirheeni täytti C-levyn totaalisesti. Levy tuli niin täyteen, ettei järjestelmää saanut alas eikä se väkisin kaatamisen jälkeen käynnistynyt uudelleen. Tämä sattui noin vuonna 1990.
En kyllä ihan ymmärrä tuota logiikkaa nyt. Mitä hyötyä tuossa ongelmassasi olisi ollut siitä että koneessa olisi ollut toinen (tyhjä) osio?
Mikset bootannut konetta vaikka korpulta ja poistanut ylimääräisiä tiedostoja C:ltä, jolloin kone luultavasti olisi taas bootannut?
Grez kirjoitti:
Aaro55 kirjoitti:
Itse olen osioinut kaikki uudet levyni useammaksi levyksi sen jälkeen, kun erään projektin testin yhteydessä ohjelmistovirheeni täytti C-levyn totaalisesti. Levy tuli niin täyteen, ettei järjestelmää saanut alas eikä se väkisin kaatamisen jälkeen käynnistynyt uudelleen. Tämä sattui noin vuonna 1990.
En kyllä ihan ymmärrä tuota logiikkaa nyt. Mitä hyötyä tuossa ongelmassasi olisi ollut siitä että koneessa olisi ollut toinen (tyhjä) osio?
Mikset bootannut konetta vaikka korpulta ja poistanut ylimääräisiä tiedostoja C:ltä, jolloin kone luultavasti olisi taas bootannut?
Veikkaan, että tuolloin täyttynyt asema olisi ollut jokin muu kuin käyttöjärjestelmän asema. Veikkaan, tosin, ettei näin 25 vuotta myöhemmin vinkit auta, kuin jatkoa ajatellen.
Itselläkin on käytäntönä osioida C vain Windowsia, ja joitakin yleisiä ohjelmia varten. Yllättävän paljon se varaa vaikka annoin 70Gt tilaa.. johtunee pagefile:n koosta 16Gt muistilla. Seuraavalla kerralla vähintään 80Gt sitten.
No ei kun sitä logiikkaa tuossa taustalla pohdin. Jotenkin kuulostaa että ohjelmointivirhe joka aiheuttaa levyn täyttymisen on aika harvinainen tapahtuma ja sen pystyy silloin sen tapahtuessa helposti korjaamaan. Yhtä hyvinhän se ohjelmointivirhe voi edelleen puskea järjestelmälevyn täyteen, vaikka kehitys tapahtuisikin toisella asemalla. Näistä syistä osiointikäyttäytymisen perustaminen tuohon yhteen tapahtumaan kuulostaa minusta oudolta, ja sen takia hainkin että oliko tuossa kenties jotain mitä en ymmärtänyt.
Itselläni jo pidemmän aikaa ollut käytäntönä osioida työkoneen koko levy yhdeksi osioksi ihan sen takia kun kaikki ei edelleenkään halua asentua täysin jollekin muulle osioille ja ottaa päähän alkaa sitten osiointeja säätämään jossain vaiheessa kun (liian pieneksi alunperin osioitu) järjestelmäosio tulee täyteen. Kaiken kaikkiaan tuntuu turhalta oman elämän hankaloittamiselta rajoittaa keinotekoisesti jotain pienemmäksi kuin olisi tarpeen. Esimerkiksi palvelimilla tilanne on eri.
User137 kirjoitti:
Itselläkin on käytäntönä osioida C vain Windowsia, ja joitakin yleisiä ohjelmia varten. Yllättävän paljon se varaa vaikka annoin 70Gt tilaa.. johtunee pagefile:n koosta 16Gt muistilla. Seuraavalla kerralla vähintään 80Gt sitten.
500 gigaa vaan suoraan, ja muille sitten pari teraa. ;)
Lebe80 kirjoitti:
Grez kirjoitti:
Aaro55 kirjoitti:
Itse olen osioinut kaikki uudet levyni useammaksi levyksi sen jälkeen, kun erään projektin testin yhteydessä ohjelmistovirheeni täytti C-levyn totaalisesti. Levy tuli niin täyteen, ettei järjestelmää saanut alas eikä se väkisin kaatamisen jälkeen käynnistynyt uudelleen. Tämä sattui noin vuonna 1990.
En kyllä ihan ymmärrä tuota logiikkaa nyt. Mitä hyötyä tuossa ongelmassasi olisi ollut siitä että koneessa olisi ollut toinen (tyhjä) osio?
Mikset bootannut konetta vaikka korpulta ja poistanut ylimääräisiä tiedostoja C:ltä, jolloin kone luultavasti olisi taas bootannut?
Veikkaan, että tuolloin täyttynyt asema olisi ollut jokin muu kuin käyttöjärjestelmän asema. Veikkaan, tosin, ettei näin 25 vuotta myöhemmin vinkit auta, kuin jatkoa ajatellen.
Siihen aikaan kovalevyn koko oli 200 MB (kyllä: megaa) ja levy maksoi 2400 mk.
Kyseessähän on aktiivisesti toimiva ohjelmistokehitysympäristö. Siellä testattiin assembler -ohejelmia, joissa hallinnoitiin interrupteja jne. Eli melkoriskialtista ympäristöä. Eikä sen ajan kehitystyökalut olleet ihan sellaisia kuin tänään.
Koneessa ei siis ole tyhjiä osioita, vaan ne on osioitu kaikki käyttöön. Tuolloisesta 200 MB:n levystä on pikku hiljaa kasvettu, mutta edelleen on käytössä sama osiointi kuin silloin. Osioiden koot ovat vain kasvaneet.
Yhtenä lisäsyynä pilkkomiseen oli backupit, joita varten oli nauha-asema. Ohjelmoin siihen nykyisten tapaisten Backup-ohjelmien tyylisen Full -ja Changed talletuksen 4Dos'in BAT:illa.
*Tuohon aikaan ohjelmistokehitysympäristö toimitettiin korpuilla. Esimerkiksi Borlandin Turbo C++ oli noin 30 korppua. Korpun koko oli 1,4 MB. Olisiko sillä saanut bootattua? Ehkä, mutta tein ratkaisun, jonka jälkeen ei ole tarvinnut pelätä ohjelmointivirhettä testauksen yhteydessä.
Nykyisin paljolla osioinnilla ei saavuttane paljonkaa hyötyjä.
Tällä hetkellä osiointini:
- C: NTFS SSD-System 98 GB Windows -Vista
- Näkymätön osio Linux'in Bootaukseen
- D: NTFS Source 214 GB
- E: Download Cache 6 GB
- F: Videos 408 GB
- G:, M:, O:, P: Removable Disk
- H: Vanha C 98 GB
- I: Old_System 99 GB
- J: New SourceE 215 GB
- K: New SavedE 196 GB
- Q: New VideoF 420 GB
No, se on kyllä ettei joku yksittäinen unohtumaan päässyt juttu pääse lopettamaan resurssia juuri sillä hetkellä kun draivi päällä.
Sitten on tietysti vielä 6 TB NAS:issa Gigabitin verkossa.
Lisäys:
User137 kirjoitti:
Itselläkin on käytäntönä osioida C vain Windowsia, ja joitakin yleisiä ohjelmia varten. Yllättävän paljon se varaa vaikka annoin 70Gt tilaa.. johtunee pagefile:n koosta 16Gt muistilla. Seuraavalla kerralla vähintään 80Gt sitten.
Minä olen nykyisin sillä kannalla että C-levyn, joka on varattu käyttöjärjestelmälle, on oltava 120 GB.
Lisäys:
Grez kirjoitti:
No ei kun sitä logiikkaa tuossa taustalla pohdin. Jotenkin kuulostaa että ohjelmointivirhe joka aiheuttaa levyn täyttymisen on aika harvinainen tapahtuma ja sen pystyy silloin sen tapahtuessa helposti korjaamaan. Yhtä hyvinhän se ohjelmointivirhe voi edelleen puskea järjestelmälevyn täyteen, vaikka kehitys tapahtuisikin toisella asemalla. Näistä syistä osiointikäyttäytymisen perustaminen tuohon yhteen tapahtumaan kuulostaa minusta oudolta, ja sen takia hainkin että oliko tuossa kenties jotain mitä en ymmärtänyt.
Kun minä testaan ohjelmiani, niin tiedän kyllä mille levylle ohjelmani kirjoittaa. Ei se voi tuhota C -levyä, jos sitä ei käytetä. Ongelmanhan aiheuttaa se, että ei ollut edes Quota -mahdollisuutta rajata levyresurssin käyttöä.
Taustalla on ehkä kammokokemukseni 1970 -luvulta, jolloin tein konekielisen patchin Singer S10 -tietoneeseen (levytilaa 10+5 MB) yhteen assembler-ohjelmaani. (Käännös olisi kestänyt noin 2h). Itse suorittamassani binaarikaannoksessa oli yhden bitin heitto ja se aiheutti sen, että ohjelma kirjoitti sattumanvaraisiin paikkoihin systeemilevyllä tiedostojärjestelmän ohittaen. Sen jälkeen vältin näitä binaaripatchejä. Tulostuksen piti tietysti tapahtua kirjoittimelle. Spoolausta koneessa ei ollut.
Ettei kyse nyt ole ihan yhdestä tapahtumasta. Lisäksi siihen aikaan, kun levyt olivat pieniä oli merkitystä kokonaisuuden kannalta myös sillä kuinka suuria tiedostoja levylle talletettiin eli levyn koko/tiedostojen koko.
Jos C-levylle allokoi liikaa tilaa, niin vanha DOS ja sittemmin myös NTFS muutti alloikointiblokin koon jopa 32 kB:een. Sinne oli sitten kiva tallettaa 1200 tiedostoa á 320 byteä, mutta levyäpä kului 38 MB. Levyn koon ollessa 120 MB, niin 38 MB on aika iso prosenttiosuus 3800/120=31,6666666666666666666667%.
NTFS:ssähän tätä pääsi sitten säätämään.
Aihe on jo aika vanha, joten et voi enää vastata siihen.