Voortgang bestanden op mp3-speler zetten

[Verwijderd]

Ik heb een wat vreemd probleem. Wanneer ik bestanden naar mijn mp3speler kopieer, bijvoorbeeld een album van zeg 60 mb, zie ik (met meerdere file managers geprobeerd) dat heel snel de bestanden gekopieerd worden, in 2 sec. lijkt het dan alsof alles al gekopieerd is, wat dan natuurlijk niet zo is. M'n mp3speler is dan gewoon nog bezig met 'Writing...', maar in X lijkt het al of het gewoon klaar is. Dit is natuurlijk niet erg handig, iemand die weet hoe dit kan?

De mp3speler wordt automatisch gemount door ivman. Wanneer ik via de terminal kopieer krijg ik wel na het uitvoeren van het cp commando gewoon pas een prompt te zien wanneer het klaar is, maar het is natuurlijk handiger te zien op hoeveel % het kopieren is in m'n grafische omgeving...

Ik werk met Gentoo, XFCE, en heb dit geprobeerd met de file managers thunar, nautilus en xfe.

[deadinspace]

Verwijderd schreef op zaterdag 02 juni 2007 @ 17:38:
Ik heb een wat vreemd probleem. Wanneer ik bestanden naar mijn mp3speler kopieer, bijvoorbeeld een album van zeg 60 mb, zie ik (met meerdere file managers geprobeerd) dat heel snel de bestanden gekopieerd worden, in 2 sec. lijkt het dan alsof alles al gekopieerd is, wat dan natuurlijk niet zo is. M'n mp3speler is dan gewoon nog bezig met 'Writing...', maar in X lijkt het al of het gewoon klaar is. Dit is natuurlijk niet erg handig, iemand die weet hoe dit kan?

Dat komt voorzover ik weet doordat de schrijfacties van de file managers gebufferd worden; op het moment dat ze de files wegschrijven naar je MP3 speler krijgt de file manager van het OS te horen dat het klaar is, terwijl het OS in werkelijkheid nog bezig is met wegschrijven. Dat is beter voor de performance. Maar dit zou ook zo moeten werken als je ze met cp kopieert, eigenlijk.

Om dat effect tegen te gaan kun je proberen je MP3 speler met de 'sync' optie te (laten) mounten.

[u_nix_we_all]

deadinspace schreef op zaterdag 02 juni 2007 @ 18:18:
[...]

Dat komt voorzover ik weet doordat de schrijfacties van de file managers gebufferd worden; op het moment dat ze de files wegschrijven naar je MP3 speler krijgt de file manager van het OS te horen dat het klaar is, terwijl het OS in werkelijkheid nog bezig is met wegschrijven. Dat is beter voor de performance. Maar dit zou ook zo moeten werken als je ze met cp kopieert, eigenlijk.

Om dat effect tegen te gaan kun je proberen je MP3 speler met de 'sync' optie te (laten) mounten.

In principe heb je gelijk, maar in de praktijk moet je daar met flash een beetje voorzichtig mee zijn. De sync optie (als die uberhaupt werkt voor FAT fs, de manpage stelt dat die optie geen effect heeft voor flash, in de praktijk blijkt van wel) kan je flash nogal "trashen"

Zie deze thread voor meer info.

[deadinspace]

u_nix_we_all schreef op zaterdag 02 juni 2007 @ 18:26:
In principe heb je gelijk, maar in de praktijk moet je daar met flash een beetje voorzichtig mee zijn.

Hmja, dat is een goed punt.

De sync optie (als die uberhaupt werkt voor FAT fs, de manpage stelt dat die optie geen effect heeft voor flash, in de praktijk blijkt van wel)

Mja, die regel uit de manpage is gewoon out of date volgensmij.

[icyx]

Volgens mij is dit juist een 'maatregel' om de levensduur van je flash chips te 'verlengen'. In de buffer van je filemanager worden alle schrijfacties 'onthouden', en bij het unmounten pas uitgevoerd. Hierdoor kan je dus wat meer 'plannen'. Stel, jij wil een album kopieren, en je zet het erop. Daarna denk je van; hey, laat ik de laatste drie nummers is weglaten, dan moet je die weer wissen, en word die data daarna weer opnieuw overschreven door nummers van een ander album. Nu zijn die sectors dus meerdere keren beschreven, wat het beperkt aantal writes van flash chips dus nadelig beinvloed. Of je dit in de praktijk zal merken is echter een ander verhaal, er kan nu al veel vaker op flash chips geschreven worden dan 'vroegah', en door inteligentere schrijfeigenschappen (niet meer steeds op dezelfde plek schrijven, maar meer 'at random') heeft dit ook een stuk minder invloed.
Voor zover ik weet is dit in ieder geval de achterliggende gedachte

[u_nix_we_all]

icyx schreef op zaterdag 02 juni 2007 @ 23:35:
Volgens mij is dit juist een 'maatregel' om de levensduur van je flash chips te 'verlengen'. In de buffer van je filemanager worden alle schrijfacties 'onthouden', en bij het unmounten pas uitgevoerd. Hierdoor kan je dus wat meer 'plannen'. Stel, jij wil een album kopieren, en je zet het erop. Daarna denk je van; hey, laat ik de laatste drie nummers is weglaten, dan moet je die weer wissen, en word die data daarna weer opnieuw overschreven door nummers van een ander album. Nu zijn die sectors dus meerdere keren beschreven, wat het beperkt aantal writes van flash chips dus nadelig beinvloed. Of je dit in de praktijk zal merken is echter een ander verhaal, er kan nu al veel vaker op flash chips geschreven worden dan 'vroegah', en door inteligentere schrijfeigenschappen (niet meer steeds op dezelfde plek schrijven, maar meer 'at random') heeft dit ook een stuk minder invloed.
Voor zover ik weet is dit in ieder geval de achterliggende gedachte

Klopt, ongeveer.....
Je filemanager heeft geen buffer, het is de caching van je FS.
En het probleem is niet zozeer de blokken data van je bestanden zelf, maar het feit dat als je de sync optie gebruikt, de FAT tabel voor iedere blok flash wat je schrijft bijgewerkt moet worden.

Je hebt gelijk dat de technologie voor flash beter geworden is (wear-levelling) maar ik weet niet of dat voor alle flash geldt, en als het toch niet zo goed werkt merk je dat pas als je flash kapot is.

edit:
Misschien is "Je filemanager heeft geen buffer" niet helemaal correct. Maar wat ik bedoel is dat het niet je filemanager is die dit gedrag veroorzaakt maar de caching van je FS.

[ Voor 5% gewijzigd door u_nix_we_all op 03-06-2007 13:41 ]

[deadinspace]

u_nix_we_all schreef op zondag 03 juni 2007 @ 13:35:
Je filemanager heeft geen buffer, het is de caching van je FS.

Nouja, die buffering gebeurt natuurlijk door het OS, en wel op de block layer, niet de FS layer. Maar dat maakt in de praktijk voor dit probleem verder weinig uit

[u_nix_we_all]

deadinspace schreef op zondag 03 juni 2007 @ 15:13:
[...]

Nouja, die buffering gebeurt natuurlijk door het OS, en wel op de block layer, niet de FS layer. Maar dat maakt in de praktijk voor dit probleem verder weinig uit

Je hebt helemaal gelijk.