mboost-dp1
unknown
Filsystemer som disse kan ikke komme hurtigt nok, imho. Så det er fedt at Microsoft gør noget ved det.
Andre systemer der minder om det er en kombination af Storage, gnomevfs og FAM.
Og så selvfølgelig ReiserFS som er med som en sort hest. Personligt tror jeg ikke ReiserFS er vejen frem, da den er for meget begrænset af den nuværende måde at benytte filer.
Der er rigtig mange Open Source programmer der har deres egen database indbygget. F. eks Evolution, Rhytmbox og Muine. Men udviklingen her er meget evolutionær, så på et tidspunkt kan man godt forestille sig at de skifter til en samlet xml baseret database.
Andre systemer der minder om det er en kombination af Storage, gnomevfs og FAM.
Og så selvfølgelig ReiserFS som er med som en sort hest. Personligt tror jeg ikke ReiserFS er vejen frem, da den er for meget begrænset af den nuværende måde at benytte filer.
Der er rigtig mange Open Source programmer der har deres egen database indbygget. F. eks Evolution, Rhytmbox og Muine. Men udviklingen her er meget evolutionær, så på et tidspunkt kan man godt forestille sig at de skifter til en samlet xml baseret database.
Jeg har læst lidt om Longhorn og det får mig til at tænke SIKKERHED.
Longhorn giver en enorm frihed til programmøren, og det ser sgu næsten ud som om denne frihed ikke er begrænset. Altså, jeg håber sgu virkeligt Microsoft gøre noget ved deres sikkerhed i stedet for at fokusere på ubrugelige funktioner. Hvad sker der hvis en virus spreder sig rundt på det åbne system?
Men altså, man må håbe at de har lært af deres mange fejl. Windows XP gjorde Windows meget stabilt, og muligvis vil Longhorn gøre Windows meget sikkert - det kan man håbe :)
Endvidere synes jeg det er fedt at de sætter nogle nye og spænende projekter i gang - i stedet for at kopiere fra de andre! Idéen med at filsystemet er "blandet op" med en rationel database er sgu meget lækkert. Især er det fedt at man som brugeren/programmøren får enorm styring over ens filer.
Longhorn giver en enorm frihed til programmøren, og det ser sgu næsten ud som om denne frihed ikke er begrænset. Altså, jeg håber sgu virkeligt Microsoft gøre noget ved deres sikkerhed i stedet for at fokusere på ubrugelige funktioner. Hvad sker der hvis en virus spreder sig rundt på det åbne system?
Men altså, man må håbe at de har lært af deres mange fejl. Windows XP gjorde Windows meget stabilt, og muligvis vil Longhorn gøre Windows meget sikkert - det kan man håbe :)
Endvidere synes jeg det er fedt at de sætter nogle nye og spænende projekter i gang - i stedet for at kopiere fra de andre! Idéen med at filsystemet er "blandet op" med en rationel database er sgu meget lækkert. Især er det fedt at man som brugeren/programmøren får enorm styring over ens filer.
Jeg tror det kan være ligemeget om de laver et nyt filsystem. Næsten alle de computerbrugere jeg snakker med til daglig, kører stadig FAT MINUS!
>:-)
>:-)
Hmmm... Have håbet de helt ville skrotte NTFS.
Jeg har af en eller andet grund ikke lyst til at køre det filsystem. Kører fat32 på alle mine diske.
Min begrundelse er jeg føler det er langsomt. Bare det at hvis man nu skal dele noget som ligger på en disk med ntfs, så tager det en evighed. Den ændre vist skrive-rettighederne på hver enkelt fil?
Synes alle andre ikke dette er træls?
Eller er det mig der har glemt at slå noget fra? :)
Eller bliver det lavet om i winFS? :D
Jeg har af en eller andet grund ikke lyst til at køre det filsystem. Kører fat32 på alle mine diske.
Min begrundelse er jeg føler det er langsomt. Bare det at hvis man nu skal dele noget som ligger på en disk med ntfs, så tager det en evighed. Den ændre vist skrive-rettighederne på hver enkelt fil?
Synes alle andre ikke dette er træls?
Eller er det mig der har glemt at slå noget fra? :)
Eller bliver det lavet om i winFS? :D
Lige et spørgsmål, nogen ser ud til at vide noget om filsystemer. Når jeg søger efter en fil på min mac, kan jeg se den gennemsøger hele min harddisk på ca 10-15 sec og finder filer der er magen til eller ligner det jeg har søgt efter.
På en windows-maskine tager samme søgning let flere minutter. Hvorfor?
Jeg ved min Panther er bygget på en sammenstykket UNIX-kerne, og kunne forestille mig det har noget med dette at gøre. Jeg ved også at filsystemet er "journalized", men har ikke præcis klarhed om hvad dette vil sige.
Hvad handler det om? Og hvordan vil Longhorn ku gøre det bedre end min Mac gør nu?
Mvh Troels
www.tijer.tk
På en windows-maskine tager samme søgning let flere minutter. Hvorfor?
Jeg ved min Panther er bygget på en sammenstykket UNIX-kerne, og kunne forestille mig det har noget med dette at gøre. Jeg ved også at filsystemet er "journalized", men har ikke præcis klarhed om hvad dette vil sige.
Hvad handler det om? Og hvordan vil Longhorn ku gøre det bedre end min Mac gør nu?
Mvh Troels
www.tijer.tk
#5
Unix har som regel et værktøj der hedder locate. Dette laver en liste af filer som er på computeren. Den bliver dog ikke automatisk opdateret så den skal opdateres en gang imellem (updatedb). Det er sikkert denne funktion MacOSX bruger (men er ikke sikker).
Windows har en lignende funktion, hurtig søgning, eller noget, som man kan slå til. Jeg tror heller ikke denne bliver opdateret automatisk.
At filsystemet er journalised, betyder bare at der bliver skrevet på disken hvor der vil blive lavet noget 'næste gang'.
Hvis systemet går ned, ved man hvor man sidst burde have skrevet noget, og man kan derfor skanne systemet for fejl på få sekunder - istedet for mange timer, hvis man har en stor disk.
NTFS har vist ikke denne funktion.
Longhorn vil kunne gøre det meget bedre end det du har nu, da filsystemet bliver en database.
Så der er praktisk taget ingen søgetid, hvis du søger på de rigtige ting.
Unix har som regel et værktøj der hedder locate. Dette laver en liste af filer som er på computeren. Den bliver dog ikke automatisk opdateret så den skal opdateres en gang imellem (updatedb). Det er sikkert denne funktion MacOSX bruger (men er ikke sikker).
Windows har en lignende funktion, hurtig søgning, eller noget, som man kan slå til. Jeg tror heller ikke denne bliver opdateret automatisk.
At filsystemet er journalised, betyder bare at der bliver skrevet på disken hvor der vil blive lavet noget 'næste gang'.
Hvis systemet går ned, ved man hvor man sidst burde have skrevet noget, og man kan derfor skanne systemet for fejl på få sekunder - istedet for mange timer, hvis man har en stor disk.
NTFS har vist ikke denne funktion.
Longhorn vil kunne gøre det meget bedre end det du har nu, da filsystemet bliver en database.
Så der er praktisk taget ingen søgetid, hvis du søger på de rigtige ting.
#4 Thile
[Hmmm... Have håbet de helt ville skrotte NTFS.
Jeg har af en eller andet grund ikke lyst til at køre det filsystem. Kører fat32 på alle mine diske.]
Neeej nej nej!... :(
*Banker i bordet*
Det kan du ikke mene...
[Min begrundelse er jeg føler det er langsomt. Bare det at hvis man nu skal dele noget som ligger på en disk med ntfs, så tager det en evighed. Den ændre vist skrive-rettighederne på hver enkelt fil?]
Øhh ja?
Det er et flerbruger system du er kommet over på.
Ikke lige som Windows 9X.
Alle NT baserede systemer har en (eller flere) super bruger(e), og begrænsede brugere for resten.
Almindelige brugere kan ikke læse hinandens filer, og ikke ændre system filer.
Det du bander langt væk er sikkerheden og filrettigheder.
[Synes alle andre ikke dette er træls?]
Måske.
Men derfra og så bruge fat32, der er fandme langt.
NTFS er ikke godt, men fat32 er forældet.
[Eller er det mig der har glemt at slå noget fra? :)
Eller bliver det lavet om i winFS? :D]
Det kan du selvfølgelig ikke slå fra. (mig bekendt)
Og det bliver, hvis ikke uændret, så forbedret yderligere.
Tilføjelsen af databasen, kan dog muligvis gøre dette hurtigere.
[Hmmm... Have håbet de helt ville skrotte NTFS.
Jeg har af en eller andet grund ikke lyst til at køre det filsystem. Kører fat32 på alle mine diske.]
Neeej nej nej!... :(
*Banker i bordet*
Det kan du ikke mene...
[Min begrundelse er jeg føler det er langsomt. Bare det at hvis man nu skal dele noget som ligger på en disk med ntfs, så tager det en evighed. Den ændre vist skrive-rettighederne på hver enkelt fil?]
Øhh ja?
Det er et flerbruger system du er kommet over på.
Ikke lige som Windows 9X.
Alle NT baserede systemer har en (eller flere) super bruger(e), og begrænsede brugere for resten.
Almindelige brugere kan ikke læse hinandens filer, og ikke ændre system filer.
Det du bander langt væk er sikkerheden og filrettigheder.
[Synes alle andre ikke dette er træls?]
Måske.
Men derfra og så bruge fat32, der er fandme langt.
NTFS er ikke godt, men fat32 er forældet.
[Eller er det mig der har glemt at slå noget fra? :)
Eller bliver det lavet om i winFS? :D]
Det kan du selvfølgelig ikke slå fra. (mig bekendt)
Og det bliver, hvis ikke uændret, så forbedret yderligere.
Tilføjelsen af databasen, kan dog muligvis gøre dette hurtigere.
#1
Nu er reiserFS i bund og grund jo bare et filsystem, jeg er godt klar over at det har database lignende funktioner, men hvis gerne vil have WinFS lignende features, kan det bare bygges oven på.
Rent performance mæssigt er ReiserFS svært at slå, det hurtigste filsystem jeg endnu har set...
Nu er reiserFS i bund og grund jo bare et filsystem, jeg er godt klar over at det har database lignende funktioner, men hvis gerne vil have WinFS lignende features, kan det bare bygges oven på.
Rent performance mæssigt er ReiserFS svært at slå, det hurtigste filsystem jeg endnu har set...
Eh? Umiddelbart minder det om det samme Microsoft havde et 30 minutters online preview af for et par måneder.
De fedeste features er nok det der XML metadata sheet eller hvad det nu var. Det var også på tide at Windows' filsystemer fik endnu en opgradering.
De fedeste features er nok det der XML metadata sheet eller hvad det nu var. Det var også på tide at Windows' filsystemer fik endnu en opgradering.
Bare for at whine:
"Toms Hardware har som nogen af de første, skrevet en artikel der kigger under hjelmen på det nye filsystem"
nej, jeg har læst 3-4 artikler om WinFS i de sidste 3-4 måneder og syntes ikke der stod noget nyt i tomshardware.com artiklen
"Toms Hardware har som nogen af de første, skrevet en artikel der kigger under hjelmen på det nye filsystem"
nej, jeg har læst 3-4 artikler om WinFS i de sidste 3-4 måneder og syntes ikke der stod noget nyt i tomshardware.com artiklen
Journaling er efterhånden noget man bør forvente sig af et moderne filsystem. På Linux har jeg kendskab til fire filsystemer med journaling ext3, reiserfs, xfs og jfs. Ext3 er en videreudvikling af ext2, de er kompatible, og den væsentligste fornyelse er journaling. Reiserfs er så vidt jeg ved designet fra grunden med journaling, og har blandt andet en filosofi om, at det skal være effektivt til både mange filer i et directory og små filer, to områder hvor andre filsystemer ikke har været særligt gode. XFS og JFS er porteret til Linux fra hhv. IRIX og OS/2. JFS er designet af IBM og bruges i både OS/2 og AIX.
Windows har ikke så stort et udvalg af journaling filsystemer som Linux. Så vidt jeg ved er NTFS det eneste officielt understøttede. Journaling giver sjældent nogen forbedring af performance, formålet er at forbedre pålideligheden af filsystemet, hvis computeren ikke bliver lukket pænt ned. De hurtige søgninger nogen systemer kan lave må altså have en anden årsag, sandsynligvis, at der findes en eller anden form for index. Sådan et index kan enten genereres af et program, der periodisk gennemsøger disken, som det f.eks. er gjort med slocate. Det kan også indbygges i filsystemet, så det automatisk opdateres.
Der vil være tale om en afvejning mellem hastigheden på forskellige operationer. En søgning kan udføres meget hurtigt, hvis et passende index altid vedligeholdes. Men alle ændringer af filsystemet vil så blive lidt langsommere. Der er mange steder, hvor man kan lave en operation meget hurtigere mod at mange andre bliver lidt langsommere. Typisk vil man gerne opnå, at ingen af de operationer man normalt udfører på filsystemet er ekstremt langsomme (lineær tid). Prisen vil i mange tilfælde være, at simple operationer, der ellers kunne gøres i konstant tid kommer til at tage logaritmisk tid.
Det kan godt være, at NTFS i nogen tilfælde er langsommere end FAT. Men der er nok tale om tilfælde, hvor FAT bruger konstant tid og NTFS bruger logaritmisk tid. Men der er situationer hvor FAT bruger lineær tid på ting, der burde kunne gøres væsentligt hurtigere. Det skyldes, at FAT bruger kædede lister til ting, som burde være gjort med en træstruktur. Sekventiel læsning af filer kører med acceptabel performance på FAT. Men søgning i store filer er simpelthen for langsomt på FAT. Ethvert andet filsystem kan gøre det bedre end FAT. Jeg plejer at bruge minix filsystemet som eksempel, fordi det er så simpelt og alligevel er langt bedre end FAT.
Men selv meget ambisøse filsystemer som f.eks. reiserfs har deres svagheder. Når nogen siger, at de synes reiserfs altid er hurtigt, så er det fordi de ikke har prøvet at arbejde med sparse files. Forskellen er så ekstrem at man knap vil tro det hvis man ikke selv har set det. Reiserfs kan bruge en halv time på en operation, som de fleste andre filsystemer kan gøre på under et sekund.
Jeg mener man skal passe på, hvor mange features man lægger i sit filsystem. Konventionerne med directories og filer er gode og gennemprøvede, og de kan bruges til stort set alt. Nogle ekstra features kan være rare. Men enhver ekstra feature er et potentielt problem for kompatibilitet. Netværksfilsystemer, partitioner delt mellem operativsystemer, arkiveringsværktøjer, mm. får problemer hver gang man laver en ny feature. Så man skal passe på. At lave et nyt filsystem, der implementerer de samme features på en mere effektiv og mere pålidelig måde er tilgengæld en langt bedre idé. Journaling gør filsystemet mere pålideligt uden at der fra programmernes synspunkt er nogen ændring. B-træer kan bruges til mere effektive datastrukturer. Det vil godt nok kræve at filsystemet formateres og der bruges nye drivere, men de samme programmer kan stadig tilgå filsystemet.
Hvis forskellige databaselignende features skal tilføjes, så vil jeg håbe, at man stadig kan backupkopiere og restore sine filer med et konventionelt værktøj og opnå det tilsigtede resultat. Der kunne f.eks. være en pseudofil i roden af filsystemet, hvorfra man altid kan læse en liste over filnavne på en effektiv måde. Uanset om pseudofilen backupkopieres eller ej, så kunne filsystemsimplementationen sikre, at pseudofilen stadig viser et korrekt indeks efter restore. Metadata, der kræver speciel håndtering af backupværktøjer er ofte uhensigtsmæssige.
Windows har ikke så stort et udvalg af journaling filsystemer som Linux. Så vidt jeg ved er NTFS det eneste officielt understøttede. Journaling giver sjældent nogen forbedring af performance, formålet er at forbedre pålideligheden af filsystemet, hvis computeren ikke bliver lukket pænt ned. De hurtige søgninger nogen systemer kan lave må altså have en anden årsag, sandsynligvis, at der findes en eller anden form for index. Sådan et index kan enten genereres af et program, der periodisk gennemsøger disken, som det f.eks. er gjort med slocate. Det kan også indbygges i filsystemet, så det automatisk opdateres.
Der vil være tale om en afvejning mellem hastigheden på forskellige operationer. En søgning kan udføres meget hurtigt, hvis et passende index altid vedligeholdes. Men alle ændringer af filsystemet vil så blive lidt langsommere. Der er mange steder, hvor man kan lave en operation meget hurtigere mod at mange andre bliver lidt langsommere. Typisk vil man gerne opnå, at ingen af de operationer man normalt udfører på filsystemet er ekstremt langsomme (lineær tid). Prisen vil i mange tilfælde være, at simple operationer, der ellers kunne gøres i konstant tid kommer til at tage logaritmisk tid.
Det kan godt være, at NTFS i nogen tilfælde er langsommere end FAT. Men der er nok tale om tilfælde, hvor FAT bruger konstant tid og NTFS bruger logaritmisk tid. Men der er situationer hvor FAT bruger lineær tid på ting, der burde kunne gøres væsentligt hurtigere. Det skyldes, at FAT bruger kædede lister til ting, som burde være gjort med en træstruktur. Sekventiel læsning af filer kører med acceptabel performance på FAT. Men søgning i store filer er simpelthen for langsomt på FAT. Ethvert andet filsystem kan gøre det bedre end FAT. Jeg plejer at bruge minix filsystemet som eksempel, fordi det er så simpelt og alligevel er langt bedre end FAT.
Men selv meget ambisøse filsystemer som f.eks. reiserfs har deres svagheder. Når nogen siger, at de synes reiserfs altid er hurtigt, så er det fordi de ikke har prøvet at arbejde med sparse files. Forskellen er så ekstrem at man knap vil tro det hvis man ikke selv har set det. Reiserfs kan bruge en halv time på en operation, som de fleste andre filsystemer kan gøre på under et sekund.
Jeg mener man skal passe på, hvor mange features man lægger i sit filsystem. Konventionerne med directories og filer er gode og gennemprøvede, og de kan bruges til stort set alt. Nogle ekstra features kan være rare. Men enhver ekstra feature er et potentielt problem for kompatibilitet. Netværksfilsystemer, partitioner delt mellem operativsystemer, arkiveringsværktøjer, mm. får problemer hver gang man laver en ny feature. Så man skal passe på. At lave et nyt filsystem, der implementerer de samme features på en mere effektiv og mere pålidelig måde er tilgengæld en langt bedre idé. Journaling gør filsystemet mere pålideligt uden at der fra programmernes synspunkt er nogen ændring. B-træer kan bruges til mere effektive datastrukturer. Det vil godt nok kræve at filsystemet formateres og der bruges nye drivere, men de samme programmer kan stadig tilgå filsystemet.
Hvis forskellige databaselignende features skal tilføjes, så vil jeg håbe, at man stadig kan backupkopiere og restore sine filer med et konventionelt værktøj og opnå det tilsigtede resultat. Der kunne f.eks. være en pseudofil i roden af filsystemet, hvorfra man altid kan læse en liste over filnavne på en effektiv måde. Uanset om pseudofilen backupkopieres eller ej, så kunne filsystemsimplementationen sikre, at pseudofilen stadig viser et korrekt indeks efter restore. Metadata, der kræver speciel håndtering af backupværktøjer er ofte uhensigtsmæssige.
Hej Kasperd
Tak for din meget fine gennemgang af fordele og ulemper ved ekstra features i et filsystem. Det gav god mening, og var lige sådan noget jeg kiggede efter.
Så må vi da håbe for Jer (ikke bestemt ment til dig Kasperd, da du virker mest linux-stemt) Windows-brugere at microsoft ikke laver en så elendig database som jeg synes windows-registry var det. Jeg mener bare, håber ikke det blir sådan man kan gemme oplysninger eller andre ting i denne registry... så det kommer fuldstændig lige så meget ude af kontrol som windows-registry gør. (Var nødt til at guide min stakkels farfar gennem RegEdit for at slette nogle ting som havde umuliggjort fornuftigt arbejde på hans computer... stakkels mand.)
Tak for din meget fine gennemgang af fordele og ulemper ved ekstra features i et filsystem. Det gav god mening, og var lige sådan noget jeg kiggede efter.
Så må vi da håbe for Jer (ikke bestemt ment til dig Kasperd, da du virker mest linux-stemt) Windows-brugere at microsoft ikke laver en så elendig database som jeg synes windows-registry var det. Jeg mener bare, håber ikke det blir sådan man kan gemme oplysninger eller andre ting i denne registry... så det kommer fuldstændig lige så meget ude af kontrol som windows-registry gør. (Var nødt til at guide min stakkels farfar gennem RegEdit for at slette nogle ting som havde umuliggjort fornuftigt arbejde på hans computer... stakkels mand.)
Det eneste jeg håber på fra Microsoft's side er at de inkluderer fil- og mapperettigheder på samme måde som man ser det i de fleste frie styresystemer. Det er den feature som jeg bedst kan lide.
#15
Absolut korrekt, reiserfs er dårlig til nogen ting, men til almindeligt brug er det min oplevelse at det er lynhurtigt. Men igen, filsystemer er ofte optimerede til enkelte opgaver, så det er jo at vælge det der er bedst. ReiserFS er godt til små filer (men elendigt til databaser, da databasen selv har et caching system og det sammen med reiserfs's caching system får tingene til at køre langsomere).
Absolut korrekt, reiserfs er dårlig til nogen ting, men til almindeligt brug er det min oplevelse at det er lynhurtigt. Men igen, filsystemer er ofte optimerede til enkelte opgaver, så det er jo at vælge det der er bedst. ReiserFS er godt til små filer (men elendigt til databaser, da databasen selv har et caching system og det sammen med reiserfs's caching system får tingene til at køre langsomere).
WinFS kommer kun til at gælde for Documents-mappen... Storage til pingvinen derimod, det rykker!
http://www.gnome.org/~seth/storage/
http://www.gnome.org/~seth/storage/
http://microsoft.sitestream.com/PDC2003/index.htm der har da længe været enorm meget information om WinFS og alt det andet nye der kommer, er for developers, men derfor kan alm brugere vel også få lidt ud af det :)
#15 Det skal lige nævnes at OpenJFS og JFS for OS/2 ikke kommer fra den samme gren af træet og de er ikke kompatible. Begge er porteret fra JFS for AIX og der ej heller er kompatibel med de to andre. Både OS/2 og AIX versionerne er stabile, det kan OpenJFS ikke beskrives som og bør ikke bruges på produktionssystemer.
Ext3 er ikke bare en videreudvikling af Ext2 - det er direkte en overbygning.
Ext3 er ikke bare en videreudvikling af Ext2 - det er direkte en overbygning.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund