Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Obecná podpora => Téma založeno: compaq 03 Prosince 2010, 15:53:51
-
Vrtá mi hlavou, proč vysypávání většího souboru z koše trvá déle, než malého?
Proč vysypání mnoha souborů trvá sekundy, když by to mělo být zlomky sekund (jako v NC v DOSu)?
-
ten dotaz myslíš opravdu vážně?
a proč lamy? ty mezi lamy určitě nepatříš.
Tak když máš v koši větší soubor tak je logocké že se maže dýl.
Pro příklad v realitě: daleko líp se vynáší koš plný papíru než železa přece :-P
Co se týká mazání více souborů....Když smažeš nějaký soubor, tak se nepřesune na nějaké místo které je vyhrazeno pro odpadky:-D ale pouze se na něm udělá značka, že je v koši a pro oči uživatele se jakoby přemístí ale přitom na disku je stále na stejném místě. Když je těchto souborů víc, musí se všechny postupně najít a smazat...což chvilku trvá.
-
jaky pouzivas souborovy system?
-
musí se všechny postupně najít a smazat...což chvilku trvá.
Neberte toto vlákno příliš vážně, ale z jiných OS a DOSu si pamatuji, že soubor byl smazán ihned nezávisle na jeho velikosti.... Takto bychom za chvilku mohli mazat 500GB soubory z koše celý den... :-) Mám ext3
-
Takto bychom za chvilku mohli mazat 500GB soubory z koše celý den...
Záleží na více aspektech, jak už jsem naznačil, než jen na velikosti.
-
a mimochodem, já v Dosu se mnohdy ukousal k smrti než se něco smazalo :-D hlavně když se mazalo víc menších souborů...
-
a mimochodem, já v Dosu se mnohdy ukousal k smrti než se něco smazalo :-D hlavně když se mazalo víc menších souborů...
v NC nebo VC? To mě se smazalo třeba 1000 souborů IHNED. Ještě jsem ani nezvedl prst z klávesnice...
-
jde o to, jestli se maze nebo "maze"
v DOSu se obvykle "mazalo" a bylo to rychle... (prvni pismenko v nazvu souboru se prepsalo specialnim znakem a bylo "smazano" - misto ktere soubor vyuzival tim bylo mozno znovu vyuzit jinym souborem)
-
a mimochodem, já v Dosu se mnohdy ukousal k smrti než se něco smazalo :-D hlavně když se mazalo víc menších souborů...
v NC nebo VC? To mě se smazalo třeba 1000 souborů IHNED. Ještě jsem ani nezvedl prst z klávesnice...
Obojí. Jak v NC tak i VC. Vzpomínám si že to trvalo i víc jak pul hodiny asi 500mb.
-
jde o to, jestli se maze nebo "maze"
v DOSu se obvykle "mazalo" a bylo to rychle... (prvni pismenko v nazvu souboru se prepsalo specialnim znakem a bylo "smazano" - misto ktere soubor vyuzival tim bylo mozno znovu vyuzit jinym souborem)
Takže to mám chápat tak, že když mažu velký soubor z koše, bezpečně se maže (bit po bitu) a místo po něm se fyzicky něčím přepisuje? To by zase trvalo ještě déle, než pár vteřin.
-
rm -rf ~/.Trash/* aj tento prikaz Ti trva dlho?
-
Přidám svoji skušenost nejdýl mi trval příkaz #rm -frv --no-preserve-root / !maže vše!a konec jsem už neviděl.
na doporučení jednoho člena fóra zde se již nevyskytujícího.
-
Přidám svoji skušenost nejdýl mi trval příkaz #rm -frv --no-preserve-root / !maže vše!a konec jsem už neviděl.
na doporučení jednoho člena fóra zde se již nevyskytujícího.
:D Stane sa.
-
Přidám svoji skušenost nejdýl mi trval příkaz #rm -frv --no-preserve-root / !maže vše!a konec jsem už neviděl.
na doporučení jednoho člena fóra zde se již nevyskytujícího.
Ak je to narazka na moj prikaz, tak v mojom som mu nekazal mazat / ale ~/.Trash/*, co je dost velky rozdiel(mazat vsetko a mazat z home adresara v adresary .Trash (kos) vsetko).
-
prd narážka nejsem slepej a pár písmenek taky umim, takže vydim rozdíl mezi / a ~/.Trash/*
-
Takže taky nechápete, proč se větší soubor vysypásá z koše déle, jako já.
-
http://www.ep.ph.bham.ac.uk/general/support/raid/raidperf11.html
-
Vysvětlení je zcela jednoduché. Na FAT*(DOS) a NTFS(Windows) je to prakticky okamžitě, protože soubory se fyzicky neodstraňují z disku. Pouze se odstraní "odkaz" na ně z tabulky - tedy, fyzicky tam jsou dál, ale už nejsou vidět, poněvadž oficiálně už neexistují a v budoucnu jsou přepsány jinými daty. Na ext3/4 (nevím jestli to bylo i na ext2) se ale skutečně fyzicky přemažou celé soubory a všechny binární hodnoty v jejich bývalém umístění se nastaví na "0" - a to pochopitelně zabere nějaký čas.
PS: Omlouvám se za nedostatek odborné terminologie :D
-
tak nějak jsem se to snažil vysvětlit i já ale zvolil jsem krkolomější zpusob.
;)
-
Na ext3/4 (nevím jestli to bylo i na ext2) se ale skutečně fyzicky přemažou celé soubory a všechny binární hodnoty v jejich bývalém umístění se nastaví na "0" - a to pochopitelně zabere nějaký čas.
To mě napadlo taky, ale laicky mě nesedělo, že se například soubor 7GB (obraz DVD) přepíše nulami jen za pár vteřin... a soubor stokrát menší za viditelný zlomek vteřiny...
-
Na ext3/4 (nevím jestli to bylo i na ext2) se ale skutečně fyzicky přemažou celé soubory a všechny binární hodnoty v jejich bývalém umístění se nastaví na "0" - a to pochopitelně zabere nějaký čas.
To mě napadlo taky, ale laicky mě nesedělo, že se například soubor 7GB (obraz DVD) přepíše nulami jen za pár vteřin... a soubor stokrát menší za viditelný zlomek vteřiny...
Laicky to klamat může. Algoritmy nejsou skoro nikdy lineární a jejich časová odezva proto může být matoucí. Tohle bych klasicky tipoval na nějaký algoritmus s logaritmickou náročností. Tedy přeloženo do češtiny - čím rychleji roste počet dat na vstupu, tím pomaleji roste doba jejich zpracování. :)
Ale taky tam může být odezva GUI, nějaká indexace, atd atd..
-
Přeloženo do laické češtiny: nebudu se tím zabývat, hlavně, že to funguje. :-)
Jako laika mě napadá, že je to možná tím, že velký soubor (stažený z netu) je fragmentovaný a tak se maže déle...
-
"Na ext3/4 (nevím jestli to bylo i na ext2) se ale skutečně fyzicky přemažou celé soubory a všechny binární hodnoty v jejich bývalém umístění se nastaví na "0""
to neni pravda, protoze by to napr. znamenalo, ze by nemohly fungovat recovery programy jako photorec
priklad:
# echo FIRZEN > file.txt
# zjistim kde se nachazi file.txt na disku
# filefrag -vs file.txt
Filesystem type is: ef53
File size of file.txt is 7 (1 block, blocksize 4096)
ext logical physical expected length flags
0 0 2141060 1 eof
file.txt: 1 extent found
# je tam
# dd if=/dev/sda5 count=1 bs=4096 skip=2141060 | hd
00000000 46 49 52 5a 45 4e 0a 00 00 00 00 00 00 00 00 00 |FIRZEN..........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000632314 s, 6.5 MB/s
# vymazu
# rm -f file.txt
# cat file.txt
cat: file.txt: No such file or directory
# sync
# furt je tam :)
# dd if=/dev/sda5 count=1 bs=4096 skip=2141060 | hd
00000000 46 49 52 5a 45 4e 0a 00 00 00 00 00 00 00 00 00 |FIRZEN..........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000414184 s, 9.9 MB/s
-
Na extX oddílech se mažou (null) inody souborů, čímž se tváří jako volné místo.
-
Zaujimava diskusia. Neviem ci si to dobre pamatam ale nieje ten rozdiel v tom ze na win. suborovych systemoch sa maze subor(prve pismeno odkazu na subor) v tabulke na zaciatku disku a v lin. suborovom systeme sa maze priamo zaciatok suboru(ako bolo pisane inode) a je potrebne viac presuvat hlavu disku? Alebo si to predstavujem zle?
-
Koho zaujima tak zaujimave poctenicko http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html (http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html)
-
@sachy
inoda jako takova se cela nevynuluje, "pouze" block pointers... a i kdyby, nevysvetluje to ten dlouhy cas mazani velkeho souboru
zacatek souboru se take nenuluje, a i kdyby, dtto :)
mozne vysvetleni viz link ktery jsem uz daval
-
@sachy
inoda jako takova se cela nevynuluje, "pouze" block pointers... a i kdyby, nevysvetluje to ten dlouhy cas mazani velkeho souboru
zacatek souboru se take nenuluje, a i kdyby, dtto :)
mozne vysvetleni viz link ktery jsem uz daval
No velky soubor bude mít (statisticky) více fragmentů, takže vymazání všech ukazatelů na bloky zabere víc času...
Ten odkyz jsem zatím jenom zběžně prohlédl, vrátím se k tomu večer...
-
U mě má víc fragmentů soubor z netu.
Příklad:
700MB film z netu má 15000 fragmentů
7GB soubor obraz DVD z DVD má 4 fragmenty
-
U mě má víc fragmentů soubor z netu.
Příklad:
700MB film z netu má 15000 fragmentů
7GB soubor obraz DVD z DVD má 4 fragmenty
To je IMHO nějak moc...vlastně každý blok toho filmu má jenom cca 500KiB - předpokládám nějaký torrent?
-
Jasně, když stahuješ několik velkých souborů najednou třeba několik dnů v kuse, tak to takhle vyjde...
-
U mě má víc fragmentů soubor z netu.
Příklad:
700MB film z netu má 15000 fragmentů
7GB soubor obraz DVD z DVD má 4 fragmenty
Jak se ten počet fragmentů dá zjistit? Zajímalo by mě to.
(Jinak je to divné, kdysi byl myslím na root.cz nějaký článek, který ukazoval, že na ext3/4 se fragmentace nekoná z důvodu toho, že se soubory na disk nezapisují za sebou ale v celkem nahodilých intervalech na různá místa a pak jsou pochopitelně nefragmentované - tedy, pokud je na disku dost místa.)
-
Jak se ten počet fragmentů dá zjistit? Zajímalo by mě to.
(Jinak je to divné, kdysi byl myslím na root.cz nějaký článek, který ukazoval, že na ext3/4 se fragmentace nekoná z důvodu toho, že se soubory na disk nezapisují za sebou ale v celkem nahodilých intervalech na různá místa a pak jsou pochopitelně nefragmentované - tedy, pokud je na disku dost místa.)
Myslíš tenhle? http://www.root.cz/clanky/proc-linux-nepotrebuje-defragmentaci/ (http://www.root.cz/clanky/proc-linux-nepotrebuje-defragmentaci/) , respektive pozdější http://www.root.cz/clanky/defragmentace-disku-v-linuxu/ (http://www.root.cz/clanky/defragmentace-disku-v-linuxu/) ?
-
...
Myslíš tenhle? http://www.root.cz/clanky/proc-linux-nepotrebuje-defragmentaci/ (http://www.root.cz/clanky/proc-linux-nepotrebuje-defragmentaci/)
Jo, přesně ten. ;)
-
U mě má víc fragmentů soubor z netu.
Příklad:
700MB film z netu má 15000 fragmentů
7GB soubor obraz DVD z DVD má 4 fragmenty
Jak se ten počet fragmentů dá zjistit? Zajímalo by mě to.
(Jinak je to divné, kdysi byl myslím na root.cz nějaký článek, který ukazoval, že na ext3/4 se fragmentace nekoná z důvodu toho, že se soubory na disk nezapisují za sebou ale v celkem nahodilých intervalech na různá místa a pak jsou pochopitelně nefragmentované - tedy, pokud je na disku dost místa.)
napr. filefrag