Fórum Root.cz

Hlavní témata => Software => Téma založeno: Martin23 21. 05. 2014, 10:39:16

Název: MC: pořadí kopírování souborů
Přispěvatel: Martin23 21. 05. 2014, 10:39:16
Deda ma moznost si na sve starsi TV prohlizet fotky pres USB port. Problem je v tom, ze ta TV neumi seradit fotky podle nazvu souboru, ale v poradi v jakem byla nakopirovana na flash disk.

Kdyz se kopiruji v "mc" fotky z adresare, soubory jsou serazeny napr. podle jmena a v tomto poradi se zkopiruji - je to ok.
Kdyz ale chci zkopirovat nekolik adresaru najednou, oznacim je a pak spustim kopirovani, soubory jsou ukladany (pro me) v nahodnem poradi a to nechci.

Je mozne nekde v "mc" nastavit, aby pri kopirovani souboru z adresaru dodrzoval poradi souboru podle jmena?
Dekuji, M.


PS: Zkousel jsem to v i v Nautilovi a poradi je stale chaoticke, ale jine nez v "mc".
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: JardaP . 21. 05. 2014, 12:25:13
Tak tohle asi nepujde, na to byste si musel patchnout MC a patch byste si musel napsat. Vyvojari jaksi nepocitali s dementnimi televizemi z Ciny.

Obavam se, ze to bud nakopirujete rucne adresar po adresari nebo si napisete skript, ktery proleze adresarovou strukturu, vytvori jeji kopii na cilovem mediu a adresar po adresari tam fotky natlaci ve spravnem poradi.
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: wamba 21. 05. 2014, 12:47:49
a když mají stejný čas, tak rovná podle názvu? nebude stačit po nakopírování spustit něco jako
Kód: [Vybrat]
find  .|sort|xargs touch
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: Pavouk106 21. 05. 2014, 12:51:38
JardaP: Buď v klidu, mám Panasonic TV a dělá to samý (já vim, já vim, taky je z Číny)

wamba: Díky za nějakej tip, až budu doma, zkusím to :-)

Martin23: Věřím tomu, že kdybys to zkopíroval v mc třikrát za sebou, bude pořadí pokaždý jiný... Tohle mi "vadí" na Linuxu všeobecně - nekopíruje se popořadě, ale nějakym záhadnym způsobem.
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: Martin23 21. 05. 2014, 13:11:23
ja ten "touch" uz taky zkousel, ale nezabralo to
ok, zkusim spachat nejakou funkcionalitu v UserMenu v "mc"
diky za reakce, M.
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: JardaP . 21. 05. 2014, 13:22:33
Martin23: Věřím tomu, že kdybys to zkopíroval v mc třikrát za sebou, bude pořadí pokaždý jiný... Tohle mi "vadí" na Linuxu všeobecně - nekopíruje se popořadě, ale nějakym záhadnym způsobem.

Pochybuji. Spis bych tipnul, ze kopiruje v poradi, v jakem soubory byly do adresare nahrany. Zkuste si na panelu MC zapnout Sort order: Unsorted a podivejte se, jestli to odpovida poradi, ve kterem se to zobrazuje na cumbedne.
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: David 21. 05. 2014, 15:03:44
Mi se uplne stejne chovaji MP3 prehravace (2 ruzne Emgetony). Proto jsem si pro kopirovani z Krusaderu napsal
Kód: [Vybrat]
#!/bin/bash

##########################################################
# Zkopiruje soubory ze zdrojoveho adresare vcetne podadresaru do cile
#
# Pouziva se z Krusaderu, proto nejsou zadne kontroly vstupu
# Nastaveni uzivatelske akce:
# ocp "%aPath("No")%" "%aEach("Selected", "Yes", "*", "No")%" "%oPath("No")%"
# Ordered copy
#  - Aktivni panel
#  -  - Samostatne volani pro kazdou vybranou polozku
#  - Protilehly panel
#  -  - Cesta panelu (oPath)
#
##########################################################

Ja="${0}"
SrcDir="${1}" # Zdrojovy adresar, napr. "/home/david/Hudba/"
CpItm="${2}"  # Kopirovana polozka, napr. "Lajny"
DstDir="${3}" # Cilovy adresar, napr. "/mnt/Emgeton/mp3.dir/"


if [ -d "${SrcDir}/${CpItm}" ]; then
mkdir -p "${DstDir}${CpItm}"
fi;

if [ -f "${SrcDir}/${CpItm}" ]; then
echo "Kopiruji \"${SrcDir}${CpItm}\"..."
cp "${SrcDir}${CpItm}" "${DstDir}${CpItm}"
fi;


ls -1 "${SrcDir}${CpItm}" | while read f; do
sleep 0.1;
if [ -d "${SrcDir}/${CpItm}/${f}" ]; then
echo "Ponoruji se do adresare \"${CpItm}\" a kopiruji \"${CpItm}/${f}\"..."
"${Ja}" "${SrcDir}${CpItm}/" "${f}" "${DstDir}${CpItm}/"
fi;
done;

ls -1 "${SrcDir}${CpItm}" | while read f; do
sleep 0.1;
if [ -f "${SrcDir}/${CpItm}/${f}" ]; then
echo "Kopiruji \"${SrcDir}${CpItm}/${f}\"..."
cp "${SrcDir}${CpItm}/${f}" "${DstDir}${CpItm}/${f}"
fi;
done;

echo "Hotovo."
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: RDa 21. 05. 2014, 16:29:02
Btw to dementni kopirovani v MC me taky stve. Uvedu nas use case:

Soubory vytvari nase aplikace - z kamery tece tok dat, ukladame snimky za sebou 0000.raw, 0001.raw, 0002.raw atd.. pekne za sebou, casove i cislovane. Po nahrati chci data okopirovat nekam... a hle, kdyz kopiruji celou slozku nebo vice slozek, soubory se kopiruji v nahodnem poradi.

Cemu to vadi: kdyz zkopirovane data chcete prehrat (cteni znova podle cisel), seek disku totalne zabiji vykon. Predpokladam, ze jakoukoliv editaci videa to bude znatelne omezovat.
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: Peter 21. 05. 2014, 16:38:51
Namiesto obvinovania mc skus fatsort  ;D

Mimochodom pre redakciu: to uz asi neexistuje debilnejsia antispamova otazka, ze?! Ja podla vas nemam nic ine na robote ako googlovat, ze ako sa po cesky povie november! A nieze ma niekto obvini z neznasanlivosti voci cechom - povazujem to za vrchol primitivizmu. Proste ide len o to, ze aj ked nemam ziaden problem s cestinou (som husakove dieta) tak mesiace som sa nikdy nevedel naucit   ::)
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: Lol Phirae 21. 05. 2014, 16:52:50
Citace
Ja podla vas nemam nic ine na robote ako googlovat, ze ako sa po cesky povie november!

http://necyklopedie.wikia.com/wiki/Drevokoc%C3%BAr
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Pavouk106 21. 05. 2014, 19:20:57
Ja podla vas nemam nic ine na robote ako googlovat, ze ako sa po cesky povie november!
Ty víš jak se to česky řekne, to Ty takhle jen píšeš, protože nesnášíš Čechy! ;D Všechno dobré ;)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: kuka 21. 05. 2014, 20:21:50
V mc nevim, ale muze pomoct prohnat to skrz tar.
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: trubicoid2 22. 05. 2014, 11:25:14
A nieze ma niekto obvini z neznasanlivosti voci cechom - povazujem to za vrchol primitivizmu.

Ty proste nesnasis cestinu :)

Napiste petici Krcmarovi, at jsou odpovedi na otazky stejne cesky a slovensky. On uz jednou oddelal odpovedi s hacky a carky na natlak verejnosti. Anebo at jsou slovensky na root.sk :)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: trubicoid2 22. 05. 2014, 11:43:53
Deda ma moznost si na sve starsi TV prohlizet fotky pres USB port. Problem je v tom, ze ta TV neumi seradit fotky podle nazvu souboru, ale v poradi v jakem byla nakopirovana na flash disk.

no myslis asi podle ctime, ne? rucne by se to udelalo
Kód: [Vybrat]
cp --preserve=timestamp v mc mas po F5 volbu preserve attributes (vsech), ale to mas asi vypnuty, protoze to bohuzel pri kopirovani na FAT rve "Cannot chown...", ale kdyz das "Skip all" tak datumy jsou v poradku, nebo?

druha moznost je nakopirovat jak chces a potom zmenit ctime podle casu, ktery je v exif tagu a mas hotovo:
Kód: [Vybrat]
jhead -ft *.jpgcoz ma vyhodu, protoze ty datumy se mohli zmenit uz mockrat a takto to opravis na skutecny (jestli mas dobre nastaveny datum ve fotaku)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Martin23 22. 05. 2014, 12:15:30
trubicoid2: problem je v necem jinem, viz. diskuze ve vlakne
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: belzebub 22. 05. 2014, 12:28:02
no myslis asi podle ctime, ne? rucne by se to udelalo
Kód: [Vybrat]
cp --preserve=timestamp v mc mas po F5 volbu preserve attributes (vsech), ale to mas asi vypnuty, protoze to bohuzel pri kopirovani na FAT rve "Cannot chown...", ale kdyz das "Skip all" tak datumy jsou v poradku, nebo?

Nejsem si jisty, ze to bude s ctime - to byt znamenalo, ze onen vyvojar PREMYSLEL nad tim, jak fotografie tridit. Pak by snad i nejvetsi hlupak pouzil jmeno, a ne ctime (coz je volani navic). Pokud je programator liny (axiom!), vypise fotky v tom poradi, v jakem je dostane z opendir/readdir, coz bude poradi v jakem se soubory zapisovaly na disk do FAT tabulky (nebo jinam podle typu FS). Pak zadny ctime ani nic podobneho nepomuze.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: trubicoid2 22. 05. 2014, 13:02:11
trubicoid2: problem je v necem jinem, viz. diskuze ve vlakne

aha, ten fat je divny  :o neumi ta televiza jeste treba exfat nebo ntfs?
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 22. 05. 2014, 13:16:55
trubicoid2: problem je v necem jinem, viz. diskuze ve vlakne

Problém je v tom, že lidi ty čínské zmetky ne a ne a nereklamují.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: trubicoid2 22. 05. 2014, 13:31:12
to se nereklamuje, to se koupi novy, ne?
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: belzebub 22. 05. 2014, 14:57:05
to se nereklamuje, to se koupi novy, ne?
Reklamace by upozornila vyrobce na to, ze lide nejsou spokojeni s funkcnosti televize. Pokud by TV kvuli te same "vade/vlastnosti" reklamovalo vic lidi, vyrobce ji opravi, protoze jinak zacne ztracet zakazniky.

Pokud si pouze koupite novy, vyrobce se ani nedozvi, ze tento problem existuje. A muzete si byt jisty, ze v tom novem TV pak bude ta chyba take.

Samozrejme je to spise hypoteticka debata, protoze realne vetsinu lidi neco podobneho vubec nezajima, nebo je ani nenapadne, ze by to mohlo jit jinak, a hykaji nadsenim nad takovymi blbostmi, jako je integraci facebooku do TV, apod.
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: Olaf 23. 05. 2014, 15:53:28
http://necyklopedie.wikia.com/wiki/Drevokoc%C3%BAr

:) :) :)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: someone 23. 05. 2014, 19:02:51
Kód: [Vybrat]
tar -s by nestacil?
Název: Re:Midnight Commnader - poradi souboru pri kopirovani adresaru
Přispěvatel: David 23. 05. 2014, 20:16:21
Mimochodom pre redakciu: to uz asi neexistuje debilnejsia antispamova otazka, ze?! Ja podla vas nemam nic ine na robote ako googlovat, ze ako sa po cesky povie november!

A druha vec - je spravna odpoved listopad nebo 11?

Ty spravne odpovedi by proste mely byt s JEN JEDNOU spravnou odpovedi!

Citace
Ve kterém měsíci proběhla sametová revoluce?:
11

Při odesílání příspěvku nastala následující chyba:
Neodpověděli jste správně na ověřovací otázky.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 23. 05. 2014, 20:24:17
Ve kterém měsíci proběhla sametová revoluce?:
11

Při odesílání příspěvku nastala následující chyba:
Neodpověděli jste správně na ověřovací otázky.

Kristepane... 11 je číslovka, ne měsíc. Hlas se v Jedličkárně.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Strýček.jedlička 01. 06. 2014, 19:19:33
Už jsem v jedličkárně :-)... kucí
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Linux141 16. 04. 2016, 19:24:02
Ano mc v pripade kopirovani vice addresaru ci adresarove struktury ma radeni podivne. Neni to jmeno, nebo cas. Mozna to souvisi z velikosti souboru, ale spis ne. Poradi zapsani souboru na disk ? Asi ne, ve win Total Commander zapisuje podle toho, jaky zvoli clovek poradi, pri aktualizaci slozky s vice soubory to nefunguje. Mozna podle polohy souboru na disku. Je poradi kopirovanych souboru pokazde jine ?
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 18. 04. 2016, 18:19:05
Ad razeni ... bere to podle sektoru na disku - proste soubor co je driv se driv prenese .... a je to tak prave proto, aby nemusel seekovat! Kdyby to mel pri kopirovani delat podle vybranyho razeni, bude to podstatne pomalejsi.

Ad otazky ... to si vas tupej browser ty odpovedi nepamatuje? Tech otazek je mozna 20, a ten muj si je pamatuje vsechny. Staci mi dvojklik a nabidne se spravna odpoved.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Pavouk106 18. 04. 2016, 18:39:43
Ehm... chlapi (linux141, j), je rok 2016, téma je dva roky starý. V mym případě teda stále platný, byl jsem doteď línej s tím experimentovat... A asi budu nadále.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: P_V 18. 04. 2016, 20:57:41
Ad razeni ... bere to podle sektoru na disku - proste soubor co je driv se driv prenese .... a je to tak prave proto, aby nemusel seekovat! Kdyby to mel pri kopirovani delat podle vybranyho razeni, bude to podstatne pomalejsi.
Vážně kopírování více souborů probíhá asynchronně popř. ve více threadech se všemi současně, aby si to OS zoptimalizoval? Protože jinak se uvedeného efektu optimalizace seekování dosáhnout nedá. Ono je nějakému userspace programu houby do toho, kde je co alokované.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Filip Jirsák 18. 04. 2016, 21:25:36
Ad razeni ... bere to podle sektoru na disku - proste soubor co je driv se driv prenese .... a je to tak prave proto, aby nemusel seekovat! Kdyby to mel pri kopirovani delat podle vybranyho razeni, bude to podstatne pomalejsi.
Vážně kopírování více souborů probíhá asynchronně popř. ve více threadech se všemi současně, aby si to OS zoptimalizoval? Protože jinak se uvedeného efektu optimalizace seekování dosáhnout nedá. Ono je nějakému userspace programu houby do toho, kde je co alokované.
To psal Jéčko, takže i kdybyste o tématu vůbec nic nevěděl, můžete si být skoro jist, že takhle to není.

Uživatelský program samozřejmě neví nic o tom, jak jsou soubory fyzicky rozmístěné na disku. Ostatně obsah souboru může být fragmentovaný, takže řídit se pořadím prvního sektoru by moc nepomohlo. Taky může být v jednom sektoru víc souborů. A také ten soubor může být na RAIDu, nebo v síťovém úložišti, tam něco jako „sektor na disku“ ani není definován.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 19. 04. 2016, 18:17:11
Vážně kopírování více souborů probíhá asynchronně popř. ve více threadech se všemi současně, aby si to OS zoptimalizoval? Protože jinak se uvedeného efektu optimalizace seekování dosáhnout nedá. Ono je nějakému userspace programu houby do toho, kde je co alokované.

Sak zdrojaky mas, tak se podivej ... a jirsaka neber vazne, ten se bez manualu nezvladne vysrat. Kdyz si od kernelu vyzadas seznam souboru, tak ti ho preda v jakym ze poradi? No presne v tom, jak sou na disku zapsany zasebou. A presne v tomhle poradi je mc kopiruje. (samo, na nekterych FS - specielne tech co umi snapy -  tohle nemusi az tak odpovidat fyzickymu rozlozeni na disku, ale prevazne to sedi dobre)

Samo, dalsi layer je disk samotnej, ten si muze req poprehazovat jeste ve vlastni rezii => pokud mu kernel nahrne seznam sektoru ktery chce cist, tak si to disk jeste interne muze prehazet tak, aby to vyhovelo jemu (predevsim pak proto, ze ani kernel musi vubec tusit, jaky je fyzicky usporadani disku).
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: ByCzech 20. 04. 2016, 04:35:11
Sak zdrojaky mas, tak se podivej ... a jirsaka neber vazne, ten se bez manualu nezvladne vysrat. Kdyz si od kernelu vyzadas seznam souboru, tak ti ho preda v jakym ze poradi? No presne v tom, jak sou na disku zapsany zasebou. A presne v tomhle poradi je mc kopiruje. (samo, na nekterych FS - specielne tech co umi snapy -  tohle nemusi az tak odpovidat fyzickymu rozlozeni na disku, ale prevazne to sedi dobre)

Samo, dalsi layer je disk samotnej, ten si muze req poprehazovat jeste ve vlastni rezii => pokud mu kernel nahrne seznam sektoru ktery chce cist, tak si to disk jeste interne muze prehazet tak, aby to vyhovelo jemu (predevsim pak proto, ze ani kernel musi vubec tusit, jaky je fyzicky usporadani disku).

Samozřejmě do hry vstupují optimalizační technologie FW disku, či NCQ (TCQ) ap., ale program dostane data v tom pořadí v jakém si je objednal. To že třeba jiný proces dostal data dříve díky, přestože si je objednal později na věci nic nemění. MC není multithreadový, aby mohlo k takovým věcem docházet.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 20. 04. 2016, 06:47:53
a jirsaka neber vazne, ten se bez manualu nezvladne vysrat. Kdyz si od kernelu vyzadas seznam souboru, tak ti ho preda v jakym ze poradi? No presne v tom, jak sou na disku zapsany zasebou.

No to jsou zase moudra, a nemůže chybět jazyk dítěte z ghetta. Pořadí souborů v adresáři nekoresponduje s layoutem souborů na disku. Řada FS (NTFS, ReiserFS) implementuje adresář jako B-tree, red-black tree nebo jiný strom, takže seznam souborů vrací vždy v abecedním pořadí.

U jiných FS (například FAT a tuším ext2) záleží na pořadí vytvoření názvů v adresáři, s tím že se znovu-používají místa v adresáři po zrušených souborech. Fyzické umístění souboru na disku určuje alokátor, a s pořadím souborů v adresáři má v nejlepším případě velmi volný vztah. Pokud na FS naroste fragmentace, tak se ten vztah vytrácí úplně. Soubory (na běžných FS) právě díky fragmentaci (souborů i volného místa) nebývají uložené ani souvisle, ani jeden za druhým. To všechno by profesionál v oblasti IT měl vědět, a navíc by to měl vědět i každý absolvent informatiky.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 20. 04. 2016, 07:50:28
Hele luliku, to tu nemusis vypislovat ze fs z dilny M$ stojej zahovno, to vsichni vime. Problemy s fragmentaci sem jinde nez na widlich nikdy neresil.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 20. 04. 2016, 12:03:39
Hele luliku, to tu nemusis vypislovat ze fs z dilny M$ stojej zahovno, to vsichni vime. Problemy s fragmentaci sem jinde nez na widlich nikdy neresil.

Všechny běžné FS trpí fragmentací. Jedním ze scénářů je paralelní zápis více souborů. FS samozřejmě neví jak budou velké. V takovém případě můžete naivně zapisovat obsah do prvního volného bloku, takže ze souborů vznikne fragmentovaná "ideální řezanka" už při zápisu. Tak primitivní alokátor samozřejmě žádný pokročilejší FS nemá. Jiná cesta je ukládat každý soubor tak aby se mu předem rezervovalo řekněme 50MB místa. Tím vznikne menší řezanka, soubory dokonce nebudou fragmentované pokud jsou menší než 50MB. Ale zase víc fragmentujete volné místo, a to se vám vymstí až se FS dostatečně zaplní, protože nenajdete dostatečně velké souvislé kusy místa. Obecně čím víc se zaplnění FS blíží ke 100%, tím vyšší bude fragmentace. A čím agresivněji jste nechával okolo souborů volné místo, abyste zabránil jejich fragmentaci, tím dřív ta fragmentace FS bude růst. Napsat dobrý alokátor holt není jednoduché.

Na klasických Unixech se defragmentovalo tak že jste provedl zálohu na pásku, smáznul FS, pak FS znovu vytvořil a provedl restore (pokud jste pásku přečetl). Dneska je to naštěstí lepší. Windows mají API pro online defrag od roku 1996, na Linuxu se online defrag postupně také začíná objevovat.

Mimochodem když píšete takové nesmysly, nemyslíte že byste se měl dovzdělat? Na první místě by to chtělo naučit se česky, ať nepůsobíte jako primitiv. To totiž nic žádná věc nezakryje. I kdybyste byl veleúspěšný v businessu, ale vyjadřoval se u toho jako dítě ghetta, tak si o vás lidé budou myslet že jste špína.
Druhá věc jsou pak znalosti IT. Nechcete si dát studium informatiky, nebo alespoň po večerech provádět samostudium? Univerzity mají dnes většinu materiálů online. Soudě podle vašich zdejších příspěvků by vám studium zatraceně hodně pomohlo.
Na dalším místě asi bude všeobecný rozhled. Jenže ten se získává dost těžko, takže tam vám moc neporadím.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: ByCzech 20. 04. 2016, 14:36:09
Hele luliku, to tu nemusis vypislovat ze fs z dilny M$ stojej zahovno, to vsichni vime. Problemy s fragmentaci sem jinde nez na widlich nikdy neresil.

Všechny běžné FS trpí fragmentací. Jedním ze scénářů je paralelní zápis více souborů. FS samozřejmě neví jak budou velké. V takovém případě můžete naivně zapisovat obsah do prvního volného bloku, takže ze souborů vznikne fragmentovaná "ideální řezanka" už při zápisu.


Vážně by bylo fajn, kdyby jste chování FS z díly Microsoftu nenavlékal na chování jiných FS, které jsou běžné v Linuxu.

Mé disky (/ a /home) po hodně dlouhém používání, paralelních zápisech, aktualizacích, mazání a novému nahrávání spousty dat, bez defragmentování (ext4):

Kód: [Vybrat]
<Fragmented files>                             now/best       size/ext
1. /var/log/wtmp.1                              26/1              4 KB
2. /var/log/wtmp                                15/1              4 KB
3. /var/log/clamav-unofficial-sigs.log          41/1              4 KB
4. /var/log/ConsoleKit/history.1                10/1              4 KB
5. /var/log/debug.1                              7/1              4 KB

 Total/best extents                             740057/738878
 Average size per extent                        75 KB
 Fragmentation score                            0
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/sda2) does not need defragmentation.
 Done.

a

Kód: [Vybrat]
<Fragmented files>                             now/best       size/ext
1. /home/jarda/.Skype/DataRv/offline-storage.data
                                                96/1              4 KB
2. /home/*censored*/.Skype/*censored*/chatsync/a3/a3753d88fe62e873.dat
                                                16/1              4 KB
3. /home/*censored*/.Skype/*censored*/chatsync/ff/ffc4dbedaa6ee36c.dat
                                                11/1              4 KB
4. /home/*censored*/.Skype/*censored*/chatsync/e0/e04921a91279e418.dat
                                                10/1              4 KB
5. /home/*censored*/.Skype/*censored*/chatsync/ea/ea920899646cf6c8.dat
                                                10/1              4 KB

 Total/best extents                             1128887/1108381
 Average size per extent                        1208 KB
 Fragmentation score                            0
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/sdb1) does not need defragmentation.
 Done.

Toto je myslím si důkazem, že v Linuxu se, jak tady již bylo řečeno, defragmentace běžně neřeší. V jakém stavu by byly disky pokud by tam byly Windowsy a NTFS všichni víme, děkujeme, že nám to potvrzujete. Ale myslím si, že to je hodně off-topic.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: lojza 20. 04. 2016, 17:06:49
neslo by to obejit treba nejak takhle:

Kód: [Vybrat]
tar cf - * | ( cd /target; tar xfp -)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 20. 04. 2016, 17:34:19
Toto je myslím si důkazem, že v Linuxu se, jak tady již bylo řečeno, defragmentace běžně neřeší. V jakém stavu by byly disky pokud by tam byly Windowsy a NTFS všichni víme, děkujeme, že nám to potvrzujete. Ale myslím si, že to je hodně off-topic.

To záleží na tom jak s FS pracujete. Když tam budete mít MySQL databázi (dá-li se tomu říkat databáze) s modelem soubor per tabulka, a budete do těch tabulek cpát spoustu dat, tak se to samozřejmě fragmentovat bude. Podobně pokud budete mít denně 1GB logů a budou se rolovat, tak se budou fragmentovat. Nebo pokud bude stroj použitý jako file server kde klienti vytvářejí a mění soubory v mnoha sessions. Nebo když si na úrovni FS transparentně zkomprimujete větší množství souborů. Nebo když budete často synchronizovat nějaký větší projekt se source control systémem a budete ho buildovat, a zároveň na FS zapisovat něco jiného. Plus se fragmentace bude zhoršovat jak se zaplnění disku bude blížit 100%, a to tím hůř, čím vyšší fragmentaci volného místa způsobil alokátor tím že se snažil zabránit fragmentaci souborů. Dalším problémem může být delayed allocator, který sice dokáže do jisté míry snížit fragmentaci, ale za cenu ztráty dat při odpojení FS natvrdo (výpadek proudu, kernel panic apod.)

Pokud máte systém na kterém se data minimálně "hýbají", tak vás fragmentace fakt nemusí trápit. Jenže ne každý při práci (resp. "práci") vystačí s xtermem, browserem a mp3 playerem :)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: JardaA 20. 04. 2016, 17:48:00
Na klasických Unixech se defragmentovalo tak že jste provedl zálohu na pásku, smáznul FS, pak FS znovu vytvořil a provedl restore (pokud jste pásku přečetl). Dneska je to naštěstí lepší. Windows mají API pro online defrag od roku 1996, na Linuxu se online defrag postupně také začíná objevovat.

Takhle se dělalo odjakživa, vzpomínám si třeba na EC1030 :-). 
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 20. 04. 2016, 18:25:48
Všechny běžné FS trpí fragmentací. Jedním ze scénářů je paralelní zápis více souborů. FS samozřejmě neví jak budou velké. ....

Mno vidis luliku, treba se widle i nekdy v daleky budoucnosti naucej pro soubor alokovat prostor predem ... kupodivu vsechny tuxi FS tak nejak od prirody udrzujou fragmentaci velmi nizkou, to jen na widlich se to naprosto pravidelne dostava do stadia, kdy je nejlepsi vsechno presunout, partysnu preformatovat a presunou zpet, protoze defragmentace by trvala par dnu a pouzivat se to neda.

Mam tady vedle sebe notes ... zajimavy cece, sou na nem widle ... bootovalo to asi 10 minut ... a po defragmentaci,  ktera bezela celej den (a tudiz to dotycnej celej den nemoh pouzivat), to zvladne teda asi za 5 ...

Pak tu mam par tuxu, nejak vlastne ani nevim, jak to defragmentovat, nikdy sem to nemel potrebu resit. Ale viz vejs, fragmentace je naprosto smesna, takze i kdybych to resil, na vykon to bude mit vliv presne 0. A to ty systemy bezej nasobne dyl nez ten notes vubec existuje.

Apropos, kdy ze M$ doda ten uzasny uber databazovy filesystem? A to samo nemuzes tusit, ze databaze si vyrobi soubor klidne nasobne vetsi, nez kolik dat aktualne ma, ze ... a ze dokonce existujou databaze, ktery si resej zcela vlastni FS (respektive FS vubec neresi).
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 20. 04. 2016, 23:27:53
No jo, Jeronýmku. Vy to víte vždycky nejlépe... nebo si to alespoň myslíte :D

Mno vidis luliku, treba se widle i nekdy v daleky budoucnosti naucej pro soubor alokovat prostor predem ... kupodivu vsechny tuxi FS tak nejak od prirody udrzujou fragmentaci velmi nizkou, to jen na widlich se to naprosto pravidelne dostava do stadia, kdy je nejlepsi vsechno presunout, partysnu preformatovat a presunou zpet, protoze defragmentace by trvala par dnu a pouzivat se to neda.
Už jsem psal, že delayed alocation vede ke ztrátě dat v případě že FS není čistě unmountován (nebo syncnut). Ale co že vaši uživatelé přijdou o data - ať si zvykají na Linux :D

Ad kupodivu vsechny tuxi FS tak nejak od prirody udrzujou fragmentaci velmi nizkou - kupodivu na většina tuxích FS se data prakticky nehýbou, případně nebyly zaplněny ke 100%. Pokud používáte xterm, browser a mp3 player, protože pro tuxe prakticky nic jiného není, tak ten FS možná opravdu moc nezfragmentujete :)

Mam tady vedle sebe notes ... zajimavy cece, sou na nem widle ... bootovalo to asi 10 minut ... a po defragmentaci,  ktera bezela celej den (a tudiz to dotycnej celej den nemoh pouzivat), to zvladne teda asi za 5 ...
To jsou super pohádky. Moje Windows bootují dost pod půl minuty (obyčejně nevypínám desktop ani notebooky, protože ty notebooky neběží na Linuxu, takže umí usnout i se pak probudit), a když jsem kdysi naposledy spustil defragmentaci, jela bez problému na pozadí. Možná byste měl přemýšlet, co děláte špatně, když vám Windows bootují 10 minut. Ale vzhledem k perlám které z vás padají ve věcech správy systému se nedivím vůbec ničemu ;)

Apropos, kdy ze M$ doda ten uzasny uber databazovy filesystem? A to samo nemuzes tusit, ze databaze si vyrobi soubor klidne nasobne vetsi, nez kolik dat aktualne ma, ze ... a ze dokonce existujou databaze, ktery si resej zcela vlastni FS (respektive FS vubec neresi).
Netuším kdy MS dodá SQL Server pro Linux, a je mi to celkem jedno, protože ho na Linuxu nebudu používat.
DB soubory samozřejmě mohou být větší než kolik je v nich dat. A samozřejmě MS SQL i Oracle umí používat RAW disky, což ale nemá moc vliv na výkon, pokud nepoužíváte nějaký úplně doprasený FS. Jako ukázku fragmentace FS jsem popisoval InnoDB v režimu File-Per-Table, a není mi úplně jasné, proč v téhle souvislosti píšete o DB souborech a RAW discích. Pozitivně hodnotím že jste ty termíny nejspíš alespoň někde slyšel, když o nich píšete.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 20. 04. 2016, 23:34:26
Moje Windows bootují dost pod půl minuty

Měl by sis to konečně ujasnit. Posledně to bylo několik sekund včetně instalace aktualizací.

a když jsem kdysi naposledy spustil defragmentaci, jela bez problému na pozadí.

A hovno zdefragmentovala, protože aby to neběželo bezvýsledně několik dní, tak to umělci z Redmondu "optimalizovali" tak, že velké soubory (kde "velký" znamená >=64MiB) se vůbec nedefragmentují.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: ByCzech 21. 04. 2016, 01:45:38
Toto je myslím si důkazem, že v Linuxu se, jak tady již bylo řečeno, defragmentace běžně neřeší. V jakém stavu by byly disky pokud by tam byly Windowsy a NTFS všichni víme, děkujeme, že nám to potvrzujete. Ale myslím si, že to je hodně off-topic.

To záleží na tom jak s FS pracujete. Když tam budete mít MySQL databázi (dá-li se tomu říkat databáze) s modelem soubor per tabulka, a budete do těch tabulek cpát spoustu dat, tak se to samozřejmě fragmentovat bude.

Strčte si ty své teorie někam. Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není. Přestaňte navlékat (špatné) zkušenosti a vlastnosti Windows na OS, který očividně neznáte.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 21. 04. 2016, 04:17:27
Strčte si ty své teorie někam. Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není. Přestaňte navlékat (špatné) zkušenosti a vlastnosti Windows na OS, který očividně neznáte.

Fragmentace je funkční vlastností všech běžných FS. Mohlo by vám to dojít i z toho že jste sám postnul výstup z e4defrag, kde máte na jednom FS Total/best extents 740057/738878, tj. 1179 zbytečných fragmentů, a na druhém Total/best extents 1128887/1108381, tj. 20506 zbytečných fragmentů. Ale hlavně že vám to magicky nefragmentuje, protože Tux. Mimochodem tohle vám měli vysvětlit ve škole v modulu Operating System Concepts, případně jste si to měl nastudovat sám, pokud chcete dělat v IT a vědět co vlastně děláte.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 21. 04. 2016, 04:34:09
Měl by sis to konečně ujasnit. Posledně to bylo několik sekund včetně instalace aktualizací.
To jste si vymyslel, nebo máte zdroj?

A hovno zdefragmentovala, protože aby to neběželo bezvýsledně několik dní, tak to umělci z Redmondu "optimalizovali" tak, že velké soubory (kde "velký" znamená >=64MiB) se vůbec nedefragmentují.
Ale vždyť zase kecáte. Vestavěný defragmenter ignoruje fragmenty větší než 64MB, protože ty už se skládají z 16384+ souvislých clusterů (po 4kB), a jejich dopad na výkon je minimální. Zato jejich konsolidace vyžaduje spoustu (efektivně zbytečných) I/O operací. To že je soubor větší než 64MB neznamená že se nedefragmentuje. Běžte si to vyzkoušet, než budete zase psát takové nesmysly.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 21. 04. 2016, 08:17:14
Strčte si ty své teorie někam. Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není. Přestaňte navlékat (špatné) zkušenosti a vlastnosti Windows na OS, který očividně neznáte.
On vi kulovy i o widlich, vubec netusi, ze M$ uz asi tak 15 let slibuje, ze NFS nahradi uzasnym databazovym filesystemem s uber vlastnostma. Sak to mela byt krucialni novinka Windows Vista ... a kde nic tu nic.

Luliku, kam ze se mam prijit na ty widle startujici do 30s podivat? To bude jako tak jitrnicka, co ji svet nevidel. Polovina widli ve firme se nevypina, a to prave proto, ze start jim trva klidne i 10 minut a vic. Ja ti pak za odmenu predvedu tucnaka, kterej startuje do 3s.

Jo jasne, tux, kterej FS nedefragmentuje vubec, tam ma ty soubory ulozeny telepaticky ... proto se prakticky nefragmentujou, zato widle na disk hrabou porad, a neustale neco prehazujou sem a tam, a presto klidne fragmentace preleze 30% ...
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: wasd 21. 04. 2016, 09:02:51
Citace
kam ze se mam prijit na ty widle startujici do 30s podivat?

Třeba ke mně. A není to ani 30s, spíš třetina. Akorát to běží na SSD + 4GHz i7... Neříkám, že si každý má kvůli startu systému pořídit herní stroj, ale ty 486 už byste mohli vyřadit.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: ByCzech 21. 04. 2016, 12:20:08
Strčte si ty své teorie někam. Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není. Přestaňte navlékat (špatné) zkušenosti a vlastnosti Windows na OS, který očividně neznáte.

Fragmentace je funkční vlastností všech běžných FS. Mohlo by vám to dojít i z toho že jste sám postnul výstup z e4defrag, kde máte na jednom FS Total/best extents 740057/738878, tj. 1179 zbytečných fragmentů, a na druhém Total/best extents 1128887/1108381, tj. 20506 zbytečných fragmentů. Ale hlavně že vám to magicky nefragmentuje, protože Tux. Mimochodem tohle vám měli vysvětlit ve škole v modulu Operating System Concepts, případně jste si to měl nastudovat sám, pokud chcete dělat v IT a vědět co vlastně děláte.

Kód: [Vybrat]
Fragmentation score                            0
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]

Mluvilo se tady o potřebě defragmentace. Chápu, že Lael zatlačený do kouta kolem sebe kouše jako divoké raněné zvíře, ale tím ukazuje, že neumí ani uznat, že je mimo, když se mu to prokáže.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 21. 04. 2016, 14:11:14
Mluvilo se tady o potřebě defragmentace. Chápu, že Lael zatlačený do kouta kolem sebe kouše jako divoké raněné zvíře, ale tím ukazuje, že neumí ani uznat, že je mimo, když se mu to prokáže.

Aha :)

Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není.

BTW to že vám defrag po analýze napíše že defragmentace volume není potřeba není nic zvláštního. Mě to píše na mých Windows také. A pokud je FS ve Windows fragmentovaný, většinou jsou fragmentovaná instalační média (třeba záloha souborů pro odinstalování service packu), která se minimálně ve Windows XP komprimují na úrovni FS. Komprese na úrovni FS zvýší fragmentaci, ale to se týká jen daných souborů, které uživatel interaktivně nepoužívá.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 21. 04. 2016, 14:22:28
On vi kulovy i o widlich, vubec netusi, ze M$ uz asi tak 15 let slibuje, ze NFS nahradi uzasnym databazovym filesystemem s uber vlastnostma. Sak to mela byt krucialni novinka Windows Vista ... a kde nic tu nic.
Zase kecáte. MS oficiálně odpískal WinFS někdy v roce 2006. WinFS by vyžadoval přepsání aplikací, a výsledkem by bylo jen to že by šly soubory hledat podle atributů, což lze udělat i na klasickém FS s fulltextovou indexací.

Luliku, kam ze se mam prijit na ty widle startujici do 30s podivat? To bude jako tak jitrnicka, co ji svet nevidel. Polovina widli ve firme se nevypina, a to prave proto, ze start jim trva klidne i 10 minut a vic. Ja ti pak za odmenu predvedu tucnaka, kterej startuje do 3s.
Myslíte že má každý 486ku s 1GB RAM a diskem který je pomalejší než slimák? :D

Jo jasne, tux, kterej FS nedefragmentuje vubec, tam ma ty soubory ulozeny telepaticky ... proto se prakticky nefragmentujou, zato widle na disk hrabou porad, a neustale neco prehazujou sem a tam, a presto klidne fragmentace preleze 30% ...
Jak jsme si ukázali, na Linuxu se FS také fragmentuje. To že fragmentace "přeleze 30%" je nic neříkající údaj, protože není jasné z čeho těch 30% počítáte. Na WinXP se komprimují instalační informace (například záloha pro případ odinstalace Service Packu), což zvyšuje fragmentaci, ale to se týká jen daných souborů, které uživatel interaktivně nepoužívá a tedy to nemá vliv. A vy podle všeho mluvíte o 14 let starých Windows XP, protože vyšší verze Windows nejspíš tyhle soubory nekomprimují, a navíc tam běží online defrag na pozadí.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 21. 04. 2016, 14:28:34
a navíc tam běží online defrag na pozadí.

Který nikdy nefungoval a velký hovno zdefragmentuje, viz onen 64MB limit...
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 21. 04. 2016, 14:48:58
Který nikdy nefungoval a velký hovno zdefragmentuje, viz onen 64MB limit...

Což je limit který jste si vymyslel, a už jsem vám to psal.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: ByCzech 21. 04. 2016, 19:01:43
Mluvilo se tady o potřebě defragmentace. Chápu, že Lael zatlačený do kouta kolem sebe kouše jako divoké raněné zvíře, ale tím ukazuje, že neumí ani uznat, že je mimo, když se mu to prokáže.

Aha :)

Je to vývojářský stroj, MySQL tam mám a hromadu databází a tabulek taky. Fragmentace tam není.

BTW to že vám defrag po analýze napíše že defragmentace volume není potřeba není nic zvláštního. Mě to píše na mých Windows také. A pokud je FS ve Windows fragmentovaný, většinou jsou fragmentovaná instalační média (třeba záloha souborů pro odinstalování service packu), která se minimálně ve Windows XP komprimují na úrovni FS. Komprese na úrovni FS zvýší fragmentaci, ale to se týká jen daných souborů, které uživatel interaktivně nepoužívá.

Opět se snažíte navlékat poznatky a informace ze světa Windows na zcela odlišné OS a opět jste za pitomce. V jiných OS to funguje jinat, to že vám něco vypisuje defrag na Windows je v Linuxu úplně irelevantní. Diskuze s vámi o ničem. Nevidíte nic než Windows a ještě blbě a myslíte si, že díky tomu víte vše o všem. Klasika. Tímto s vámi hovor opět končím, s psychopatem co si pořád mele svou i přes předložené data a informace se bavit nehodlám.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 21. 04. 2016, 20:04:14
Opět se snažíte navlékat poznatky a informace ze světa Windows na zcela odlišné OS a opět jste za pitomce. V jiných OS to funguje jinat, to že vám něco vypisuje defrag na Windows je v Linuxu úplně irelevantní. Diskuze s vámi o ničem. Nevidíte nic než Windows a ještě blbě a myslíte si, že díky tomu víte vše o všem. Klasika. Tímto s vámi hovor opět končím, s psychopatem co si pořád mele svou i přes předložené data a informace se bavit nehodlám.

Souhlas v tom že statistiky fragmentace se liší nástroj od nástroje. Ovšem vy statistiky svého nástroje považujete za důkaz toho že na vašem FS není potřeba defragmentovat, a ještě to zobecňujete na každý případ použití daného FS, a ještě se dozvíme že "fragmentace tam není", když tam zcela zjevně je.

Také končím diskusi. Pokud tvrdíte "fragmentace tam není" a přikládáte výpis kde fragmentace je, tak bychom se mohli bavit leda o vaší diagnóze, což je ztráta času.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: atarist 21. 04. 2016, 20:38:38
A pokud je FS ve Windows fragmentovaný, většinou jsou fragmentovaná instalační média (třeba záloha souborů pro odinstalování service packu), která se minimálně ve Windows XP komprimují na úrovni FS. Komprese na úrovni FS zvýší fragmentaci...

A proč by měla? Kvůli tomu, že OS nezná dopředu délku souboru? Ale to obecně nezná i v mnoha dalších případech, takže by si s tím měl poradit ne?
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 21. 04. 2016, 22:56:53
..(třeba záloha souborů pro odinstalování service packu), která se minimálně ve Windows XP komprimují na úrovni FS. Komprese na úrovni FS zvýší fragmentaci, ale to se týká jen daných souborů, které uživatel interaktivně nepoužívá.

What? tvle to co hulis to chci ... to musi bejt sila ... XP ani zadnej jinej widlosystem nic na urovni FS nekomprimuje, dokud tu kompresi nad necim admin nezapne. Navic komprese ma s framentaci spolecny asi tak to, ze se to tyce oboji souboru ...

a navíc tam běží online defrag na pozadí.

Který nikdy nefungoval a velký hovno zdefragmentuje, viz onen 64MB limit...
Tj, sak taky proto vsichni pouzivaji vsemozny defragmentatory tretich stran, a to uz od DOSu a nortona ... Pokud vim, M$ se jeste furt nenaucil defragmentovat vlastni swap pripadne tu uspavaci hruzu ...
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 22. 04. 2016, 00:07:13
Tak Mrkvošrot se nikdy nenaučil defragmentovat, už asi 20 let si licencují vykuchané verze Diskeeperu, čemuž taky odpovídají schopnosti defragmentace u té bundlované srágory.  ;D ::)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 22. 04. 2016, 07:44:25
A proč by měla? Kvůli tomu, že OS nezná dopředu délku souboru? Ale to obecně nezná i v mnoha dalších případech, takže by si s tím měl poradit ne?

NTFS komprimuje soubor po 16 clusterech (obyčejně 64kB). Pokud je soubor původně nekomprimovaný a kompresi na něm zapnete, tak se prvních 64kB souboru zkomprimuje řekněme na 32kB, a zbylých 32kB se dealokuje. To se provede pro každý kompresní blok. Pokud kompresí bloku (64kB) nedojde k uvolnění žádného clusteru (4kB), tak se uloží nekomprimovaný.
Každý design má své výhody a nevýhody. Tenhle je dobrý v tom že umožňuje okamžitý přístup k jakékoliv části souboru bez nutnosti dekomprimovat celý soubor, nevyžaduje pro provedení komprese místo na disku, a při sekvenci compress-decompress nezvyšuje fragmentaci. Nevýhodou je zvyšování fragmentace existujících souborů při jejich kompresi. Ta nevýhoda se ale projevuje dost omezeně, protože se zpravidla komprimují soubory, ke kterým se nepřistupuje často.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 22. 04. 2016, 09:12:58
What? tvle to co hulis to chci ... to musi bejt sila ... XP ani zadnej jinej widlosystem nic na urovni FS nekomprimuje, dokud tu kompresi nad necim admin nezapne. Navic komprese ma s framentaci spolecny asi tak to, ze se to tyce oboji souboru ...
Jistě, vy tomu rozumíte nejlíp. Zjevně jste neviděl pořádně ani ty WinXP. FYI modré složky jsou komprimované.
http://www.edbott.com/weblog/wp-content/images/uninstall_files.jpg

a navíc tam běží online defrag na pozadí.

Který nikdy nefungoval a velký hovno zdefragmentuje, viz onen 64MB limit...
Tj, sak taky proto vsichni pouzivaji vsemozny defragmentatory tretich stran, a to uz od DOSu a nortona ... Pokud vim, M$ se jeste furt nenaucil defragmentovat vlastni swap pripadne tu uspavaci hruzu ...
Jak jsem opakovaně psal, Lol Phirae si ten limit vymyslel.
Ano, Windows podporují defragmentatory tretich stran. Nabízejí jim API nezávislé na verzi FS. Třeba se na Linuxu něco takového jednou také naučíte :). Používání defrag utilit třetích stran sice nemá valný význam, ale jestli se vám líbí, tak si je užijte.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363911(v=vs.85).aspx

Ohledně defragmentace swapu: je pěkné, že jste se po letech kdy "defrag nebyl potřeba" naučili na Linuxu defragmentovat. Pokud tedy použijete správný FS, a máte trochu toho štěstíčka, aby vám to FS nezbořilo :). Ale pokud jsem si všiml, tak swap (a nejspíš ani jiné otevřené soubory) třeba takový e4defrag defragmentovat neumí. Proč asi?
http://manpages.ubuntu.com/manpages/precise/man8/e4defrag.8.html
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 22. 04. 2016, 09:14:36
Tak Mrkvošrot se nikdy nenaučil defragmentovat, už asi 20 let si licencují vykuchané verze Diskeeperu, čemuž taky odpovídají schopnosti defragmentace u té bundlované srágory.  ;D ::)
A to jste si vymyslel, stejně jako to že se údajně nedefragmentují soubory větší než 64MB, nebo v tomto případě máte výjimečně i nějaký zdroj? ;)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: dustin 22. 04. 2016, 09:37:35
Pár našich čísel:

XFS, workstation, SSD s velkým git projektem a denně aktualizovou (rsyncem) mysql innodb files per table, compass db (předchůdce elasticsearch), 50% plno

Kód: [Vybrat]
actual 245249, ideal 222462, fragmentation factor 9,29%
XFS, stejná workstation, normální denní provoz kořenový fs, 27% plno:

Kód: [Vybrat]
actual 373938, ideal 369220, fragmentation factor 1,26%
XFS, SSD, server, velice aktivní mysql innodb files per table (slave k produkčnímu serveru, obsah úplně stejný jako na výše uvedené workstation), velký git projekt s běžícím CI serverem, zaplnění 55%:

Kód: [Vybrat]
actual 238114, ideal 234700, fragmentation factor 1.43%

XFS, SSD, server, opět kopie mysql files per table, aktualizace rsyncem, poměrně aktivní mongodb, zaplnění 54%

Kód: [Vybrat]
actual 16592, ideal 4383, fragmentation factor 73.58%
XFS, SSD, server, master velice aktivní mysql files per table (90GB, pořád obsahově ta samá), zaplnění 40%

Kód: [Vybrat]
actual 7926, ideal 4640, fragmentation factor 41.46%
XFS, SSD, server, primár pro velice aktivní mongodb (18 GB) zaplnění 12%

Kód: [Vybrat]
actual 14472, ideal 150, fragmentation factor 98.96%

XFS, SSD, server, slave velice aktivní mysql files per table (90GB, pořád obsahově ta samá), compass zaplnění 45%

Kód: [Vybrat]
actual 6020, ideal 4438, fragmentation factor 26.28%
XFS, SSD, server, sekundár velice aktivní mongodb (90GB, pořád obsahově ta samá), zaplnění 8%

Kód: [Vybrat]
actual 10830, ideal 52, fragmentation factor 99.52%
Takže mongodb dělá na XFS s fragmentací psí kusy. 90GB aktivní mysql asi taky.

Nicméně všechno jsou to SSD (s pravidelně spouštěným fstrimem), takže to nijak neřeším.

Na výsledek frag u klasických HDD jsem nečekal, jsou to všechno mnohaTB pole.

Očividně i v XFS na linuxu dochází k fragmentaci (souhlasím s Laelem, že to je z principu nevyhnutelné). Nicméně by se mi vůbec nelíbilo, kdyby mi něco spouštělo defragmentaci na pozadí. A faktem je, že jsem defragmentaci na linuxu nikdy nespouštěl a máme řadu mnoho let starých dost aktivních filesystémů s milióny souborů, které jednou vznikly a pak už jenom rostly spolu s raidovými poli, nikdy nebyly překopírované. A řešit to nebudu ani nyní :-)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 22. 04. 2016, 10:41:39
Očividně i v XFS na linuxu dochází k fragmentaci (souhlasím s Laelem, že to je z principu nevyhnutelné). Nicméně by se mi vůbec nelíbilo, kdyby mi něco spouštělo defragmentaci na pozadí. A faktem je, že jsem defragmentaci na linuxu nikdy nespouštěl a máme řadu mnoho let starých dost aktivních filesystémů s milióny souborů, které jednou vznikly a pak už jenom rostly spolu s raidovými poli, nikdy nebyly překopírované. A řešit to nebudu ani nyní :-)

No vida, vidím že vy máte víc zkušeností, než jen s vlastním desktopem.

Ohledně defragmentace na pozadí: tu Windows automaticky pouštějí jen na desktopu. Na serveru ne, protože se tam předpokládá, že admin bude vědět jak vypadá zátěž a jaké implikace má defragmentační proces.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: dustin 22. 04. 2016, 11:07:26
Nemám zkušenosti s windows, proto se k nim nevyjadřuji. Doporučil bych to samé vám ohledně linuxu, také o něm téměř nic nevíte.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 22. 04. 2016, 12:18:28
Nemám zkušenosti s windows, proto se k nim nevyjadřuji. Doporučil bych to samé vám ohledně linuxu, také o něm téměř nic nevíte.

Tvrdil jsem tu jen zcela zjevné věci, které těžko rozporovat:
- Pořadí souborů v adresáři nekoresponduje s pořadím souborů na disku, a to ani na Linuxu.
- FS běžného typu fragmentují, a to i na Linuxu, protože je to jejich funkční vlastnost.
- Není pravda že defrag na Windows soubory větší než 64MB ignoruje.
- Ve WinXP se komprimují soubory pro odinstalaci Service Packu, a to zvyšuje fragmentaci těch souborů.
- Moje Windows bootují dost pod půl minuty.

Linuxu se týkají první dva body. Pokud se domníváte že říct "FS běžného typu fragmentují, a to i na Linuxu" smí jen člověk který má Tuxe na tričku i na notebooku, tak tedy pardon :)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: dustin 22. 04. 2016, 13:54:05
Žvásty typu

Citace
Ad kupodivu vsechny tuxi FS tak nejak od prirody udrzujou fragmentaci velmi nizkou - kupodivu na většina tuxích FS se data prakticky nehýbou, případně nebyly zaplněny ke 100%. Pokud používáte xterm, browser a mp3 player, protože pro tuxe prakticky nic jiného není, tak ten FS možná opravdu moc nezfragmentujete

Víte velké kulové, kolik mají firmy na linuxu dat, protože jej neznáte, neumíte, nepoužíváte. Jenom tady o něm plácáte nesmysly. Jděte pomáhat svým lidem, to bude aspoň užitečné.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 22. 04. 2016, 14:12:42
Žvásty typu

Citace
Ad kupodivu vsechny tuxi FS tak nejak od prirody udrzujou fragmentaci velmi nizkou - kupodivu na většina tuxích FS se data prakticky nehýbou, případně nebyly zaplněny ke 100%. Pokud používáte xterm, browser a mp3 player, protože pro tuxe prakticky nic jiného není, tak ten FS možná opravdu moc nezfragmentujete

Víte velké kulové, kolik mají firmy na linuxu dat, protože jej neznáte, neumíte, nepoužíváte. Jenom tady o něm plácáte nesmysly. Jděte pomáhat svým lidem, to bude aspoň užitečné.

Pánové argumentovali svými desktopy, na kterých se data většinou moc nehýbají, zvlášť pokud dotyčný primárně administruje jiné systémy přes xterm a píše na root z browseru :). To se už víc data hýbají na desktopu s Windows, protože MSIE používá cache s mnoha soubory, kdežto třeba Firefox používá pár velikých souborů.

Mimochodem vy víte kolik mají firmy dat na Linuxu? Nebo to víte u jedné či pár firem, které máte v dosahu? To když odhlédnu od toho že vůbec netušíte, co mám okolo sebe já. Na okraj bych ještě podotknul, že (dost možná na rozdíl od vás) minimálně dva zdejší diskutéři neznají pořádně Linux, Windows, ani nic jiného.
https://en.wikipedia.org/wiki/Selection_bias
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: David1234 22. 04. 2016, 14:23:06
Na okraj bych ještě podotknul, že (dost možná na rozdíl od vás) minimálně dva zdejší diskutéři neznají pořádně Linux, Windows, ani nic jiného.

A co my s tím jako, koho to zajímá? Mají za to snad dostat ban? :D Mimochodem, odpověděl vůbec někdo na původní dotaz? Existuje nějaké řešení?
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: dustin 22. 04. 2016, 14:39:42
To když odhlédnu od toho že vůbec netušíte, co mám okolo sebe já.

Očividně ne firmy, které linux aktivně používají, protože jej vůbec neumíte. A právě proto se zde k němu prosím nevyjadřujte a držte se své specializace.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 22. 04. 2016, 15:25:52
vůbec netušíte, co mám okolo sebe já

To skutečně netuším, já to totiž vím naprosto přesně. Hromadu vymytých mozků.  ;D ;D ;D
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: x14 22. 04. 2016, 15:28:56
Slušná debata ;D ;D ;D
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 22. 04. 2016, 15:33:10
NTFS komprimuje soubor po 16 clusterech (obyčejně 64kB). Pokud je soubor původně nekomprimovaný a kompresi na něm zapnete, tak se prvních 64kB souboru zkomprimuje řekněme na 32kB, a zbylých 32kB se dealokuje. To se provede pro každý kompresní blok. Pokud kompresí bloku (64kB) nedojde k uvolnění žádného clusteru (4kB), tak se uloží nekomprimovaný....

Jasne, tohle by muselo napsat podobny hodvadko, jako ses ty. Protoze na komprimovanym FS se komprimuje jeste driv, nez se to vubec ulozi. Takze to funguje presne stejne, jako kdyz si dotycnej uklada rovnou zip.


...
Ano, Windows podporují defragmentatory tretich stran. Nabízejí jim API nezávislé na verzi FS. ...
Megalol ... a proto ty defragmentatory tretich stran hrabou primo na fyzicky sektory na disku, zejo?

..
Mimochodem vy víte kolik mají firmy dat na Linuxu? ...
Vime .... uplne vsechny ... vis luliku, dneska se kupodivu (prakticky yplne vsude) pouziva virtualizace... a tu widlowsi ... nepouziva vubec nikdo.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 22. 04. 2016, 17:20:09
To když odhlédnu od toho že vůbec netušíte, co mám okolo sebe já.

Očividně ne firmy, které linux aktivně používají, protože jej vůbec neumíte. A právě proto se zde k němu prosím nevyjadřujte a držte se své specializace.

Pokud máte konkrétní výhrady, tak sem s nimi. Argumenty stylu "protože jej vůbec neumíte. A právě proto se zde k němu prosím nevyjadřujte a držte se své specializace" neberu.

vůbec netušíte, co mám okolo sebe já

To skutečně netuším, já to totiž vím naprosto přesně. Hromadu vymytých mozků.  ;D ;D ;D

Huš!
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 22. 04. 2016, 17:35:33
NTFS komprimuje soubor po 16 clusterech (obyčejně 64kB). Pokud je soubor původně nekomprimovaný a kompresi na něm zapnete, tak se prvních 64kB souboru zkomprimuje řekněme na 32kB, a zbylých 32kB se dealokuje. To se provede pro každý kompresní blok. Pokud kompresí bloku (64kB) nedojde k uvolnění žádného clusteru (4kB), tak se uloží nekomprimovaný....

Jasne, tohle by muselo napsat podobny hodvadko, jako ses ty. Protoze na komprimovanym FS se komprimuje jeste driv, nez se to vubec ulozi. Takze to funguje presne stejne, jako kdyz si dotycnej uklada rovnou zip.

Si tacuisses, philosophus mansisses. Když vytváříte nový soubor v komprimovaném adresáři, tak se samozřejmě nefragmentuje. A srovnávat transparentní kompresi na FS se ZIPem je z více důvodů naprostá pitomost.

...
Ano, Windows podporují defragmentatory tretich stran. Nabízejí jim API nezávislé na verzi FS. ...
Megalol ... a proto ty defragmentatory tretich stran hrabou primo na fyzicky sektory na disku, zejo?

Které konkrétně? Třeba Diskeeper pokud vím používá od NT4 defragmentační API. Verze FS se totiž může klidně zítra změnit patchem, a s ní i on-disk structures. Používání nedokumentovaných vlastností OS je jak známo prasárna, zde navíc s potenciálem způsobit ztrátu dat.

..
Mimochodem vy víte kolik mají firmy dat na Linuxu? ...
Vime .... uplne vsechny ... vis luliku, dneska se kupodivu (prakticky yplne vsude) pouziva virtualizace... a tu widlowsi ... nepouziva vubec nikdo.

Hmm. Máte nějaká konkrétní data, Jeronýmku, nebo zase jen tak plácáte? Tipnu si že B.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 22. 04. 2016, 17:50:39
Které konkrétně? Třeba Diskeeper pokud vím používá od NT4 defragmentační API.

Ehm. Diskeeper je ta věc, kterou jste si museli licencovat, protože jste nebyli schopní nic vlastního vyplodit. Už jsme tě tady na to taktně upozorňovali  ::)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 22. 04. 2016, 18:15:13
Které konkrétně? Třeba Diskeeper pokud vím používá od NT4 defragmentační API.

Ehm. Diskeeper je ta věc, kterou jste si museli licencovat, protože jste nebyli schopní nic vlastního vyplodit. Už jsme tě tady na to taktně upozorňovali  ::)

Ale, kdo to nepřišel :). Takže kde jsem podle vás psal, že se moje Windows rebootují několik sekund včetně aktualizací? Zdroj?
http://forum.root.cz/index.php?topic=9090.msg163980#msg163980

Proč lžete že se soubory větší než 64MB na Windows nedefragmentují?
http://forum.root.cz/index.php?topic=9090.msg163980#msg163980
https://blogs.msdn.microsoft.com/e7/2009/01/25/disk-defragmentation-background-and-engineering-the-windows-7-improvements/

No a nakonec: máte nějaký zdroj k tomu že defrag v poslední verzi Windows je licencovaný Diskeeper?
Svého času to tak bylo, ale na tom přece není nic špatného. Nakonec na Linuxu si Linus půjčil glibc a prakticky veškeré tools od GNU. Je to hnus a Linus je neschopný? Nebo to bylo prostě snazší řešení?
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: nobody(ten pravej) 22. 04. 2016, 19:00:54
Lael.Ophir:
http://www.root.cz/clanky/postrehy-z-bezpecnosti-kriticka-chyba-schannel-postihujici-windows/nazory/523906/
http://www.root.cz/clanky/postrehy-z-bezpecnosti-kriticka-chyba-schannel-postihujici-windows/nazory/523950/
kdybys radeji misto toho PR zaridil aby rozesranej WindowUpdate na W7SP1 fungovat*1 bez potreby rucne instalovat novej WindowsUpdateAgent a fixovat naborene registry, na CISTE nainstalovanejch W7+SP1...

*1) alespon tak dementne jak to maji windows navrhnute a tedy netvalo vyhledani aktualizaci nekolik dni az vecnost...
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 22. 04. 2016, 19:16:53
kdybys radeji misto toho PR zaridil aby rozesranej WindowUpdate na W7SP1 fungovat*1 bez potreby rucne instalovat novej WindowsUpdateAgent a fixovat naborene registry, na CISTE nainstalovanejch W7+SP1...

Klik, Maloměk už usilovně pracuje na tom, aby to nefungovalo vůbec. Hotfixy od května pouze přes IE-only Microsoft Update Catalog (http://www.askwoody.com/2016/future-windows-patches-only-available-in-the-update-catalog/), kde navíc nefunguje HTTPS, případně přes WSUS, který poslední aktualizací rozmrdali tak, že je nepoužitelný (http://www.infoworld.com/article/3060241/microsoft-windows/botched-wsus-patch-kb-3148812-still-throws-errors-80244019-80244008-and-8024401f.html).
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: hawran diskuse 22. 04. 2016, 23:32:10
...
Používání nedokumentovaných vlastností OS je jak známo prasárna, zde navíc s potenciálem způsobit ztrátu dat...
;D  ;D  ;D
Blue on blue?
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 23. 04. 2016, 07:36:50
Klik, Maloměk už usilovně pracuje na tom, aby to nefungovalo vůbec. Hotfixy od května pouze přes IE-only Microsoft Update Catalog (http://www.askwoody.com/2016/future-windows-patches-only-available-in-the-update-catalog/), kde navíc nefunguje HTTPS, případně přes WSUS, který poslední aktualizací rozmrdali tak, že je nepoužitelný (http://www.infoworld.com/article/3060241/microsoft-windows/botched-wsus-patch-kb-3148812-still-throws-errors-80244019-80244008-and-8024401f.html).

On stejne ten wsus nikdy pouzitelnej nebyl ... moznosti nastavit co kde instalovat a co ne? Presne 0. Teda jasne, muzes rucne schvalovat patche pro kazdej stroj extra - kdyz si pro kazdej extra udelas skupinu. A i to se posere, protoze ten uzasne snap-in ... je tak bombackej, ze startuje 10 minut i na 32 jadrovym stroji ... a na kazdej klik reaguje tak 2-3 minuty, aby se ve finale zhroutil na timeout. Driv nebo pozdejs (= tak do 14 dni nejpozdejs) se to posere cely zcela garantovane. Neumi to smazat nepotrebny patche (to ani v pripade, ze je na disku nemas), nikdy to nedobehne. A jako bonus dostanes, ze ten snap-in uz pak nenastartuje vubec, takze se proste ani nepodivas, co je a co neni opatchovany. A i kdyz ses nahodou jeste ve fazi, ze se podivat muzes, tak jediny co zjistis, ze kazdej tvuj system nezbytne potrebuje 186 patchu ... pricemz ti patchovator na strane toho systemu hlasi, ze zadny dalsi patche nejsou k dizpozici ... aneb tisicistrankova diskuse na webu M$ na tema, jak sou v M$ kreteni, ktery jazykovy balicky oznacej jako potrebnou zaplatu. Jo ... muzes je (opet pro kazdou verzi systemu extra) pekne rucne prochazet a zakazovat ... lol.

O tom, ze se ti na 100 zcela totoznych strojich instalujou ruzny patche, a jeste k tomu zcela random se na kazdym podela jinej ani nemluve.

Kolega minulej tejden patchoval notes co se nakou dobu povaloval ve skladu ... 3 dny.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 24. 04. 2016, 17:42:07
Poslední zážitek s Maloměkem - W10 neumí pracovat s MBR disky. (Po nedobrovolném upgradu z W7 - do Redmondu vřelé díky a vostnáč do análu - jsem chtěl známému zazálohovat dokumenty a fotky a počítač přeinstalovat.) Rozdělám bednu, připojím přes SATA 500GB starý disk, protože přes USB 2.0 jsem to fakt tahat nechtěl. Disk byl předem naformátován na NTFS. Poslední zázrak z dílny negramotů však místo NTFS detekoval RAW filesystém a v diskpartu byl volume offline. Nahodit online se samozřejmě nedal.

Nevadí. Oddíl jsem v diskpartu smazal, vytvořil znova. OK. Následuje format fs=ntfs quick - kdepak. Prý nesprávná volba. Pouštím diskmgmt.msc, oddíl opět mažu, vytvářím znova, volím NTFS přes celý disk a rychlé formátování. Kdepak. Formátování se nezdařilo, právě vytvořený oddíl je prý offline. A skutečně. Znova diskpart, dávám clean a reboot. Windows najde nový disk a chce ho inicializovat, defaultně nabízí MBR. Potvrzuji, s takhle malým diskem není důvod dělat něco jiného. Opět ta stejná story.

Stahuji asi tři různé partition utility a zkouším v nich. Oddíl sice zdárně naformátován, leč Redmondím morem okamžitě označen jako offline a NTFS se tváří opět jako RAW.

V záchvatu nasrání opět dávám clean v diskpartu, reboot. Windows nachází disk, chce ho inicializovat, nabízí defaultně MBR. Seru na to a volím GPT. Opět dávám vytvořit NTFS oddíl přes celý disk. Zázrak - volume je online, formátování proběhlo, písmenko přiřazeno, můžeme zálohovat.

Světe div se, samotný systém je nainstalován na MBR disku a s tím Windows problém nemá.

Tímto posílám vřelý víkendový pozdrav Laelovi do Redmondu a vzkazuji: Sto kokotov do riti a hrdzavú kotvu do chrbta, kreténi!!!  >:( >:( >:( >:( >:( >:(

(https://cdn.meme.am/instances/20225294.jpg)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 25. 04. 2016, 09:46:34
Jo ... to si predstav, ze si takhle (bez tech M$ kokotin) udelas truecrypt volume (pres celej disk samo) ... a widle ti pri kazdym startu budou nadavat, ze mas v systemu neinicializovanej disk ... a kdyz nekdo klipne na inicializovat, tak sou data v riti. Na druhou stranu, truecrypt to pripoji a bez kecu to funguje ... ;D
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 25. 04. 2016, 15:38:35
Lael.Ophir:
http://www.root.cz/clanky/postrehy-z-bezpecnosti-kriticka-chyba-schannel-postihujici-windows/nazory/523906/
http://www.root.cz/clanky/postrehy-z-bezpecnosti-kriticka-chyba-schannel-postihujici-windows/nazory/523950/
kdybys radeji misto toho PR zaridil aby rozesranej WindowUpdate na W7SP1 fungovat*1 bez potreby rucne instalovat novej WindowsUpdateAgent a fixovat naborene registry, na CISTE nainstalovanejch W7+SP1...

*1) alespon tak dementne jak to maji windows navrhnute a tedy netvalo vyhledani aktualizaci nekolik dni az vecnost...

No vida, já psal o rebootu pod půl minuty a s instalací tehdejšího patche za minutu čtyřicet. To jsou přece běžné hodnoty. Těch "několik sekund" je holt něčím výmysl.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 25. 04. 2016, 15:42:28
kdybys radeji misto toho PR zaridil aby rozesranej WindowUpdate na W7SP1 fungovat*1 bez potreby rucne instalovat novej WindowsUpdateAgent a fixovat naborene registry, na CISTE nainstalovanejch W7+SP1...

Klik, Maloměk už usilovně pracuje na tom, aby to nefungovalo vůbec. Hotfixy od května pouze přes IE-only Microsoft Update Catalog (http://www.askwoody.com/2016/future-windows-patches-only-available-in-the-update-catalog/), kde navíc nefunguje HTTPS, případně přes WSUS, který poslední aktualizací rozmrdali tak, že je nepoužitelný (http://www.infoworld.com/article/3060241/microsoft-windows/botched-wsus-patch-kb-3148812-still-throws-errors-80244019-80244008-and-8024401f.html).

Jak už jsme si vysvětlovali, HTTPS není potřeba protože jsou patche digitálně podepsané, a z webu Windows Catalogu je možné je stáhnout i aplikací třetí strany, jako je například WSUS Offiline (který má s MS WSUS společný jen kus názvu). Ale jinak dobrý FUD :)
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 25. 04. 2016, 15:47:03
Klik, Maloměk už usilovně pracuje na tom, aby to nefungovalo vůbec. Hotfixy od května pouze přes IE-only Microsoft Update Catalog (http://www.askwoody.com/2016/future-windows-patches-only-available-in-the-update-catalog/), kde navíc nefunguje HTTPS, případně přes WSUS, který poslední aktualizací rozmrdali tak, že je nepoužitelný (http://www.infoworld.com/article/3060241/microsoft-windows/botched-wsus-patch-kb-3148812-still-throws-errors-80244019-80244008-and-8024401f.html).

On stejne ten wsus nikdy pouzitelnej nebyl ... moznosti nastavit co kde instalovat a co ne? Presne 0. Teda jasne, muzes rucne schvalovat patche pro kazdej stroj extra - kdyz si pro kazdej extra udelas skupinu. A i to se posere, protoze ten uzasne snap-in ... je tak bombackej, ze startuje 10 minut i na 32 jadrovym stroji ... a na kazdej klik reaguje tak 2-3 minuty, aby se ve finale zhroutil na timeout. Driv nebo pozdejs (= tak do 14 dni nejpozdejs) se to posere cely zcela garantovane. Neumi to smazat nepotrebny patche (to ani v pripade, ze je na disku nemas), nikdy to nedobehne. A jako bonus dostanes, ze ten snap-in uz pak nenastartuje vubec, takze se proste ani nepodivas, co je a co neni opatchovany. A i kdyz ses nahodou jeste ve fazi, ze se podivat muzes, tak jediny co zjistis, ze kazdej tvuj system nezbytne potrebuje 186 patchu ... pricemz ti patchovator na strane toho systemu hlasi, ze zadny dalsi patche nejsou k dizpozici ... aneb tisicistrankova diskuse na webu M$ na tema, jak sou v M$ kreteni, ktery jazykovy balicky oznacej jako potrebnou zaplatu. Jo ... muzes je (opet pro kazdou verzi systemu extra) pekne rucne prochazet a zakazovat ... lol.

O tom, ze se ti na 100 zcela totoznych strojich instalujou ruzny patche, a jeste k tomu zcela random se na kazdym podela jinej ani nemluve.

Kolega minulej tejden patchoval notes co se nakou dobu povaloval ve skladu ... 3 dny.

U WSUS je potřeba čas od času nechat proběhnout ten maintenance wizard. Pokud ho rok neprojdete, tak to běží zatraceně dlouho. Pak je potřeba zvolit vždy jednu položku (od konce seznamu), a to za pár hodin zafunguje. Osobně se mi WSUS moc nelíbí, ale faktem je, že funguje.

Ad muzes rucne schvalovat patche pro kazdej stroj extra kdyz si pro kazdej extra udelas skupinu - tady zase někdo nepochopil princip. Pointa WSUS je právě v tom, že schvalujete instalaci patchů hromadně.

Ad na 100 zcela totoznych strojich instalujou ruzny patche, a jeste k tomu zcela random se na kazdym podela jinej ani nemluve - zajímavé že vám nikdy nic nefunguje. Vidím pár WSUS serverů, které prostě fungují jak mají. U jednoho bylo potřeba pročistit DB, protože na ní admin-prase pár let nesáhnul. Jinak v pohodě.

Ad Kolega minulej tejden patchoval notes co se nakou dobu povaloval ve skladu ... 3 dny - jinými slovy asi existoval dobrý důvod, proč takovou plečku schovat do skladu :D
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 25. 04. 2016, 15:52:59
Poslední zážitek s Maloměkem - W10 neumí pracovat s MBR disky. (Po nedobrovolném upgradu z W7 - do Redmondu vřelé díky a vostnáč do análu - jsem chtěl známému zazálohovat dokumenty a fotky a počítač přeinstalovat.) Rozdělám bednu, připojím přes SATA 500GB starý disk, protože přes USB 2.0 jsem to fakt tahat nechtěl. Disk byl předem naformátován na NTFS. Poslední zázrak z dílny negramotů však místo NTFS detekoval RAW filesystém a v diskpartu byl volume offline. Nahodit online se samozřejmě nedal.

Nevadí. Oddíl jsem v diskpartu smazal, vytvořil znova. OK. Následuje format fs=ntfs quick - kdepak. Prý nesprávná volba. Pouštím diskmgmt.msc, oddíl opět mažu, vytvářím znova, volím NTFS přes celý disk a rychlé formátování. Kdepak. Formátování se nezdařilo, právě vytvořený oddíl je prý offline. A skutečně. Znova diskpart, dávám clean a reboot. Windows najde nový disk a chce ho inicializovat, defaultně nabízí MBR. Potvrzuji, s takhle malým diskem není důvod dělat něco jiného. Opět ta stejná story.

Stahuji asi tři různé partition utility a zkouším v nich. Oddíl sice zdárně naformátován, leč Redmondím morem okamžitě označen jako offline a NTFS se tváří opět jako RAW.

V záchvatu nasrání opět dávám clean v diskpartu, reboot. Windows nachází disk, chce ho inicializovat, nabízí defaultně MBR. Seru na to a volím GPT. Opět dávám vytvořit NTFS oddíl přes celý disk. Zázrak - volume je online, formátování proběhlo, písmenko přiřazeno, můžeme zálohovat.

Světe div se, samotný systém je nainstalován na MBR disku a s tím Windows problém nemá.

Tímto posílám vřelý víkendový pozdrav Laelovi do Redmondu a vzkazuji: Sto kokotov do riti a hrdzavú kotvu do chrbta, kreténi!!!  >:( >:( >:( >:( >:( >:(

(https://cdn.meme.am/instances/20225294.jpg)

Windows s MBR disky bez problémů funguje, alespoň u mě a všude kde jsem to potřeboval. U vás za tím může být třeba nějaká "ochrana" antiviru nebo BIOSu, co já vím. Mimochodem kdyby například každý uživatel Linuxu křičel něco o kokotech do riti když jako neprivilegovaný uživatel nemůže ani použít klíčenku kterou někdo zapsal na jiném stroji, protože jsou na ní inteligentně permissions a inteligentně na každém stroji pro jiné UID, tak by řvali všichni uživatelé Linuxu.

Jo a připomněl jste mi příhodu, kdy jsem se pokoušel založit na Linuxu na RAIDu 16 partition. Bohužel limit je 15 partitions. Velmi vtipné je to každá utilita hází jinou chybovou hlášku, a žádná smysluplnou. No jo, je (skoro-)Unix :). Nejsem ale cholerik, abych potřeboval ventilovat cosi o kokotech do riti. Nakonec jestli jste cholerik, tak si u každého z těchto problémů můžete zařvat. Ale on je tu Tux, takže se problémy nepočítají, že? ;)
http://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: P_V 25. 04. 2016, 16:19:43
Na FAT32 že jsou nějaké permissions?
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 25. 04. 2016, 16:49:40
...
Tady spis nekdo vubec netusi, ze pointa patchovani je v tom, ze si nastavim 10, 20, 30 setu pravidel, podle toho, jak se kterej stroj pouziva, a podle toho se taky patchuje, coz se s widlema udelat neda, ze luliku ...

Takze abych toho dosahnul ve widlich, tak si na to musim poridit nastroje tretich stran.

Jo, adminem myslis samo M$ zejo? Protoze ty stroje byly ciste nainstaleny widle. A ta plecka bylo i5 s ssd ...
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 25. 04. 2016, 18:00:02
Na FAT32 že jsou nějaké permissions?

Na FAT32 ne. Na ext2/3/4 ano.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: P_V 25. 04. 2016, 18:15:02
A to jo, kdo si jako správný hipster naformátuje flashku v nějakém platformně specifickém fs a navíc určeném na něco jiného, tak ty problémy s permišny a hartusení na ně jsou součástí jeho image. *

* nikoli image na disku, ale image dojmologického
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 25. 04. 2016, 18:30:16
U WSUS je potřeba čas od času nechat proběhnout ten maintenance wizard. Pokud ho rok neprojdete, tak to běží zatraceně dlouho.

Kterej dělá sám o sobě lautr hovno. Ve skutečnosti je potřeba všechny ty dříve schválené, nyní superseeded hotfixy nejdřív ručně odmítnout. Což ten křáp neumí ani v poslední reinkarnaci.

Windows s MBR disky bez problémů funguje, alespoň u mě a všude kde jsem to potřeboval. U vás za tím může být třeba nějaká "ochrana" antiviru nebo BIOSu, co já vím.

Jistě. A taky ti instalace aktualizací včetně restartu trvá několik sekund.

Žádný antivirus (krom toho Defender zmetka defaultně instalovaného s Wokny) ani ochrana BIOSu tam nebyla, kdybys použil tu tykev na hlavě k myšlení, tak by tě něco takového ani nenapadlo, protože mezi inicializací disku na GPT a MBR z tohoto hlediska není žádný rozdíl, stejně se tam vytvoří protective MBR.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 25. 04. 2016, 18:33:45
...
Tady spis nekdo vubec netusi, ze pointa patchovani je v tom, ze si nastavim 10, 20, 30 setu pravidel, podle toho, jak se kterej stroj pouziva, a podle toho se taky patchuje, coz se s widlema udelat neda, ze luliku ...

Takze abych toho dosahnul ve widlich, tak si na to musim poridit nastroje tretich stran.

Jo, adminem myslis samo M$ zejo? Protoze ty stroje byly ciste nainstaleny widle. A ta plecka bylo i5 s ssd ...

Proč bych si dělal desítky sad pravidel? Když naházím všechny stroje do jedné skupiny, tak prostě patch schválím a nainstaluje se jen tam, kde je potřeba. Pokud chci patche předem otestovat na menší skupině strojů (lab, early adopters), tak zřídím jednu nebo dvě skupiny. Jinými slovy těch skupin může být víc než jedna, ale nevidím důvod aby jich byly desítky.

Ad musim poridit nastroje tretich stran - například SCCM je nástroj od MS.

Ad ta plecka bylo i5 s ssd - váš kolega by si měl buď vytvořit opatchovaná instalační média, nebo stáhnout patche pomocí WSUS Offline a nainstalovat je hromadně. To když odhlédnu od faktu že 6 let starý OS, a není jediný důvod ho na stroji nechávat.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: nobody(ten pravej) 25. 04. 2016, 18:34:19
Lael.Ophir:
http://www.root.cz/clanky/postrehy-z-bezpecnosti-kriticka-chyba-schannel-postihujici-windows/nazory/523906/
http://www.root.cz/clanky/postrehy-z-bezpecnosti-kriticka-chyba-schannel-postihujici-windows/nazory/523950/
kdybys radeji misto toho PR zaridil aby rozesranej WindowUpdate na W7SP1 fungovat*1 bez potreby rucne instalovat novej WindowsUpdateAgent a fixovat naborene registry, na CISTE nainstalovanejch W7+SP1...

*1) alespon tak dementne jak to maji windows navrhnute a tedy netvalo vyhledani aktualizaci nekolik dni az vecnost...

No vida, já psal o rebootu pod půl minuty a s instalací tehdejšího patche za minutu čtyřicet. To jsou přece běžné hodnoty. Těch "několik sekund" je holt něčím výmysl.

pokud je minuta ctyricet bezna, co zareagovat na tu cast kde pisu o nekolik dni az vecnost? je to rozesrane schvalne aby m$ znasilnil lidi k w10, nebo je m$ jen neschopnej opravit rozesr&nej windows update? muzes si to vyzouset, ciste W7 instalace, nahodis SP1 (je jedno jestli offline instalace, nebo v ramci update, kde nejdirv vsecny ostatni patche, nebo naopak SP1 co nejdirv) a po restartu uz WindowsUpdate hleda a nikdy nezkonci...
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 25. 04. 2016, 18:37:26
A to jo, kdo si jako správný hipster naformátuje flashku v nějakém platformně specifickém fs a navíc určeném na něco jiného, tak ty problémy s permišny a hartusení na ně jsou součástí jeho image. *

* nikoli image na disku, ale image dojmologického

Já myslel že právě FAT32 je to microsoftí ultra-zlo, a minimálně uživatelé Linuxu by měli používat svobodný a ještě svobodnější extX. Dokonce jsem se v diskusích na rootu dočetl, že by výrobci měli vzít za svůj nějaký linuxový open source FS, a na microsoftí FAT se vykašlat. Jak se ukazuje, tak extX nefunguje na removable mediích v běžných scénářích ani uživatelům Linuxu.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 25. 04. 2016, 18:45:51
Lael.Ophir:
http://www.root.cz/clanky/postrehy-z-bezpecnosti-kriticka-chyba-schannel-postihujici-windows/nazory/523906/
http://www.root.cz/clanky/postrehy-z-bezpecnosti-kriticka-chyba-schannel-postihujici-windows/nazory/523950/
kdybys radeji misto toho PR zaridil aby rozesranej WindowUpdate na W7SP1 fungovat*1 bez potreby rucne instalovat novej WindowsUpdateAgent a fixovat naborene registry, na CISTE nainstalovanejch W7+SP1...

*1) alespon tak dementne jak to maji windows navrhnute a tedy netvalo vyhledani aktualizaci nekolik dni az vecnost...

No vida, já psal o rebootu pod půl minuty a s instalací tehdejšího patche za minutu čtyřicet. To jsou přece běžné hodnoty. Těch "několik sekund" je holt něčím výmysl.

pokud je minuta ctyricet bezna, co zareagovat na tu cast kde pisu o nekolik dni az vecnost? je to rozesrane schvalne aby m$ znasilnil lidi k w10, nebo je m$ jen neschopnej opravit rozesr&nej windows update? muzes si to vyzouset, ciste W7 instalace, nahodis SP1 (je jedno jestli offline instalace, nebo v ramci update, kde nejdirv vsecny ostatni patche, nebo naopak SP1 co nejdirv) a po restartu uz WindowsUpdate hleda a nikdy nezkonci...

Mám za to, že jsem v nějaké dřívější diskusi linkoval patch.

Ad pokud je minuta ctyricet bezna, co zareagovat na tu cast kde pisu o nekolik dni az vecnost - ten samý patch?
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 25. 04. 2016, 18:47:48
U WSUS je potřeba čas od času nechat proběhnout ten maintenance wizard. Pokud ho rok neprojdete, tak to běží zatraceně dlouho.

Kterej dělá sám o sobě lautr hovno. Ve skutečnosti je potřeba všechny ty dříve schválené, nyní superseeded hotfixy nejdřív ručně odmítnout. Což ten křáp neumí ani v poslední reinkarnaci.

Windows s MBR disky bez problémů funguje, alespoň u mě a všude kde jsem to potřeboval. U vás za tím může být třeba nějaká "ochrana" antiviru nebo BIOSu, co já vím.

Jistě. A taky ti instalace aktualizací včetně restartu trvá několik sekund.

Žádný antivirus (krom toho Defender zmetka defaultně instalovaného s Wokny) ani ochrana BIOSu tam nebyla, kdybys použil tu tykev na hlavě k myšlení, tak by tě něco takového ani nenapadlo, protože mezi inicializací disku na GPT a MBR z tohoto hlediska není žádný rozdíl, stejně se tam vytvoří protective MBR.

Aha :). Automatické odmítnutí patchů je přesně to co dělá kork Superseded updates toho wizardu.

Několik sekund? Konkrétně jsem uváděl v jednom konkrétním případu 100 sekund. Asi máme odlišnou představu o tom co znamená "několik".

Nevím proč u vás MBR disky nefungují, ale vím že mě na všech strojích fungují.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 25. 04. 2016, 18:51:46
Aha :). Automatické odmítnutí patchů je přesně to co dělá kork Superseded updates toho wizardu.

Ne. Nedělá. Dovzdělej se nebo drž hubu ohledně věcí, které jsi zjevně nikdy nepoužil a absolutně NIC o nich nevíš... Už to je fakt únavný.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/1d18e922-39ad-440b-aeb7-0c4f4a8bd08d/best-practice-to-clean-up-wsus-content-no-longer-needed
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lama 25. 04. 2016, 21:52:44
Mě hlavně fascinuje, jak zástupce firmy produkující takový shit jako W10 si dovoluje kritizovat konkurenční systémy.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: j 25. 04. 2016, 22:50:02
...
Ad ta plecka bylo i5 s ssd - váš kolega by si měl buď vytvořit opatchovaná instalační média, nebo stáhnout patche pomocí WSUS Offline a nainstalovat je hromadně. To když odhlédnu od faktu že 6 let starý OS, a není jediný důvod ho na stroji nechávat.
Jiste lulliku a to instalacni medium sezene kde? Aha, nikde ... a wsus offline mu pomuze leda tak jak? Aha, taky nijak ... a ono se dobre instalujou opathovany widle pres system s hromadou appek, nejlepe tak, aby tam ty appky zustaly ... zejo ... to M$ taky zvlada excelentne.

A ten zbytek, megalol, leda magor muze i jen zkouset pouzivat 8/10. Ten neexistujici duvod je asi tak ... miliarda aplikaci ktery nefungujou (z toho desitky jen u mych zakosu), a pak taky to, ze uzivatele maji jinou praci, za kterou sou placeni, nez mesic co mesic ty desiky reinstalovat cely, a na svym mobilnim pripojeni stahovat GB dat.

Mimochodem, nevsim sem si ze by wpkg bylo z dilny M$, mozna proto to proste funguje. A vis ty co? U desitek aplikaci zjisteni novych verzi trva tak 2-3 vteriny. Zjisteni novych verzi u gentoo vcetne syncu kompletniho stromu ... do 2 minut.

pokud je minuta ctyricet bezna, co zareagovat na tu cast kde pisu o nekolik dni az vecnost? je to rozesrane schvalne aby m$ znasilnil lidi k w10, nebo je m$ jen neschopnej opravit rozesr&nej windows update? muzes si to vyzouset, ciste W7 instalace, nahodis SP1 (je jedno jestli offline instalace, nebo v ramci update, kde nejdirv vsecny ostatni patche, nebo naopak SP1 co nejdirv) a po restartu uz WindowsUpdate hleda a nikdy nezkonci...
Rozesrate je to i na win10, a jako bonus se ti kazdej mesic sosne 5GB patchu - teda cely widle znova. A extrabonus je, ze co ctvrtrok se ti ty widle reinstalnou, a smaznou ti 1/2 appek. Moooc dobry pokud delas nekde admina. Zjevne si M$ mysli, ze admini maj howno co na praci.

A pro vseobecny pobaveni, M$ exchange ... rozesranou databazi to pozna az v okamziku, kdy se ji chcete pokusit obnovit ze zalohy, kde je samo rozesrana taky. A jak se na to prijde? Mno ... treba tak, ze "chova nevysvetlitelne divne". Ne ten exchange, ale ty widle na kterych to bezi. Ale potesilo ... padlo definitivni rozhodnuti ze nastupce bude 100% mit maildir.

Apropos, schvalne .. at se lulan vytahne ... mejme disk, totozny soubory zabiraj 2/3 obsazenyho prostoru. A ted at se vyprsi s M$ resenim. Podotykam, ze user si svuj soubor obcas zedituje a je nepripustny, aby editoval cizi.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: nobody(ten pravej) 25. 04. 2016, 22:54:13
Mám za to, že jsem v nějaké dřívější diskusi linkoval patch.

jednak rucni stazeni nejakych KB rozhodne neni reseni pro BFU, takove reseni ma v rukouch M$, kdyz by pro Windows7 ktere stale podporuje, opravil na serveru aby se dostupny WindowsAgent po aplikace SP1 byl schopen pripojit a dostal patricne soubory potrebne pro napravu problemu ktere M$ zpusobil na WidnowsUpdate serverech...

ale schvalne najdi ten link na patch o kterem pises, jestli bude jeden z tech 3-4 co dle meho zjisteni je potreba nainstalovat, ale nepomuze to vzdy, mezitim je nekolikrat potreba fixnout registry a naborene wu... i tak je nakonec casto nemozne vyhledat aktualizace rucne, ale musi se nastavit cas automatickych ktere vyhledaji ale nekdy nenainstaluji (i kdyz je nastaveno automaticky instalovat) a po nucenem automatickem hledani je pak treba vyvolat instalaci rucne, ale zustava to casto pro zmenu vyset, takze je treba to sledovat a cas od casu zkouknout jestli i presto ze stale bezi prubeh (ktery je schopny bezet i 2 dny, dele sem to nenechaval), tak jestli tlacitko vypnout nema vykricnik, pokud ano, nasilim uzivatel restartuje, a da znovu instalovat, kdyz to trva nekolik hodin, zas muze zkouknout jestli uz neni nahodou vykricnik i presto ze se wu tvari ze instaluje, da se restart, a znova instalovat zas o nekolik aktualizaci mene...

no proste totalne ROZESR&NEJ uz tak koncepcne ZPRASENE-DEMENTNI WindowsUpdate... ale jak sem psal, M$ to ten problem schvalne neresi (resp. ho nejspis schvalne umele vytvoril), protoze doufa ze znasilni dalsi uzivatele aby z W7 nucene presli na W10...
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 26. 04. 2016, 07:55:15
Aha :). Automatické odmítnutí patchů je přesně to co dělá kork Superseded updates toho wizardu.

Ne. Nedělá. Dovzdělej se nebo drž hubu ohledně věcí, které jsi zjevně nikdy nepoužil a absolutně NIC o nich nevíš... Už to je fakt únavný.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/1d18e922-39ad-440b-aeb7-0c4f4a8bd08d/best-practice-to-clean-up-wsus-content-no-longer-needed

No jistě :)
https://static.spiceworks.com/images/how_to_steps/0000/6859/WSUS_Cleanup.jpg
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 26. 04. 2016, 08:23:41
Jiste lulliku a to instalacni medium sezene kde? Aha, nikde ... a wsus offline mu pomuze leda tak jak? Aha, taky nijak ... a ono se dobre instalujou opathovany widle pres system s hromadou appek, nejlepe tak, aby tam ty appky zustaly ... zejo ... to M$ taky zvlada excelentne.
Instalační médium se SP1 umí stáhnout Windows 10 Media Creation Tool. Integraci dalších patchů lze provést pomocí utility dism.exe.
WSUS Offline pomůže tak že umožní jednou stáhnout patche, a pak je offline aplikovat. Je to rychlejší.

A ten zbytek, megalol, leda magor muze i jen zkouset pouzivat 8/10. Ten neexistujici duvod je asi tak ... miliarda aplikaci ktery nefungujou (z toho desitky jen u mych zakosu), a pak taky to, ze uzivatele maji jinou praci, za kterou sou placeni, nez mesic co mesic ty desiky reinstalovat cely, a na svym mobilnim pripojeni stahovat GB dat.

Které *konkrétní* aplikace podle vás nefungují na Windows 8/10? Nemusíte jich vypisovat miliardu, stačí tisíc těch na které jste osobně narazil :)

Mimochodem, nevsim sem si ze by wpkg bylo z dilny M$, mozna proto to proste funguje. A vis ty co? U desitek aplikaci zjisteni novych verzi trva tak 2-3 vteriny. Zjisteni novych verzi u gentoo vcetne syncu kompletniho stromu ... do 2 minut.

Aha. A když máte na disku jinou verzi než je indikovaná v instalační databázi, tak smůla, zůstanete bez patche. Wow!

Rozesrate je to i na win10, a jako bonus se ti kazdej mesic sosne 5GB patchu - teda cely widle znova. A extrabonus je, ze co ctvrtrok se ti ty widle reinstalnou, a smaznou ti 1/2 appek. Moooc dobry pokud delas nekde admina. Zjevne si M$ mysli, ze admini maj howno co na praci.

Ale blbost. Win10 netahají každý měsíc 5GB patchů, a nemažou každý čtvrtek půlku aplikací. Když si vymýšlíte, zkuste to alespoň tak aby to bylo uvěřitelné :)

A pro vseobecny pobaveni, M$ exchange ... rozesranou databazi to pozna az v okamziku, kdy se ji chcete pokusit obnovit ze zalohy, kde je samo rozesrana taky. A jak se na to prijde? Mno ... treba tak, ze "chova nevysvetlitelne divne". Ne ten exchange, ale ty widle na kterych to bezi. Ale potesilo ... padlo definitivni rozhodnuti ze nastupce bude 100% mit maildir.

Jinými slovy jste si rozesral Exchange, a pak jste zákazníkovi "vysvětlil", že za to vlastně může ošklivý MS, a řešením je to že workgroup SW nahradíte pomocí primitivního mailserveru. Vás bych chtěl mít jako IT outsourcera :D

Apropos, schvalne .. at se lulan vytahne ... mejme disk, totozny soubory zabiraj 2/3 obsazenyho prostoru. A ted at se vyprsi s M$ resenim. Podotykam, ze user si svuj soubor obcas zedituje a je nepripustny, aby editoval cizi.
Co by s tím podle vás měl MS dělat? Na serveru můžete použít data deduplication. Ale na prvním místě bych se zamyslel, proč vůbec máte tolik totožných souborů. Pokud to tak je, tak místní IT asi nedělá dobře svou práci.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 26. 04. 2016, 08:25:45
Aha :). Automatické odmítnutí patchů je přesně to co dělá kork Superseded updates toho wizardu.

Ne. Nedělá. Dovzdělej se nebo drž hubu ohledně věcí, které jsi zjevně nikdy nepoužil a absolutně NIC o nich nevíš... Už to je fakt únavný.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/1d18e922-39ad-440b-aeb7-0c4f4a8bd08d/best-practice-to-clean-up-wsus-content-no-longer-needed

No jistě :)
https://static.spiceworks.com/images/how_to_steps/0000/6859/WSUS_Cleanup.jpg

Zoufalče, vysvětlení, co ten cleanup dělá, máš na tom linku na Technetu. Ten cleanup NEvyčistí žádnou approved aktualizaci. Ani tu, která je superseeded jinou aktualizací. NEvyčístí ani jedinou schválenou aktualizaci u mezitím odebraného produktu. Nic z toho to nedělá. Desítky a stovky GB hnoje tam budou do doby, než ho přehrabeš ručně.

Citace
In order for the Server Cleanup Wizard to decline an update it must either be expired or superseded. Furthermore, superseded updates must be NotApproved, the replacement update must be Approved, and the superseded update must have been 100% Installed/NotApplicable for at least 30 days.

Jinými slovy - když o té věci víš hovno, tak proboha nepoučuj.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 26. 04. 2016, 08:37:00
jednak rucni stazeni nejakych KB rozhodne neni reseni pro BFU, takove reseni ma v rukouch M$, kdyz by pro Windows7 ktere stale podporuje, opravil na serveru aby se dostupny WindowsAgent po aplikace SP1 byl schopen pripojit a dostal patricne soubory potrebne pro napravu problemu ktere M$ zpusobil na WidnowsUpdate serverech...

BFU dostane systém předinstalovaný a opatchovaný, nejvýš si stáhne patche za posledních pár měsíců. Admin by měl umět stáhnout patche.
Ten popisovaný problém s tím že WU nenajde updaty je opravdu způsobený na serveru? Pokud jsem si všiml, tak se to stává jen na některých stanicích.

ale schvalne najdi ten link na patch o kterem pises, jestli bude jeden z tech 3-4 co dle meho zjisteni je potreba nainstalovat, ale nepomuze to vzdy, mezitim je nekolikrat potreba fixnout registry a naborene wu... i tak je nakonec casto nemozne vyhledat aktualizace rucne, ale musi se nastavit cas automatickych ktere vyhledaji ale nekdy nenainstaluji (i kdyz je nastaveno automaticky instalovat) a po nucenem automatickem hledani je pak treba vyvolat instalaci rucne, ale zustava to casto pro zmenu vyset, takze je treba to sledovat a cas od casu zkouknout jestli i presto ze stale bezi prubeh (ktery je schopny bezet i 2 dny, dele sem to nenechaval), tak jestli tlacitko vypnout nema vykricnik, pokud ano, nasilim uzivatel restartuje, a da znovu instalovat, kdyz to trva nekolik hodin, zas muze zkouknout jestli uz neni nahodou vykricnik i presto ze se wu tvari ze instaluje, da se restart, a znova instalovat zas o nekolik aktualizaci mene...

Existují různé problémy s WU. MS mimo jiné nabízí wizarda při potížích s WU, který jich většinu řeší. Ale WU mimo jiné píše logy. Jako uživatel Linuxu jste přece zvyklý luštit hromady logů a hledat v nich příčinu problémů. Měl byste být nadšený :)

no proste totalne ROZESR&NEJ uz tak koncepcne ZPRASENE-DEMENTNI WindowsUpdate... ale jak sem psal, M$ to ten problem schvalne neresi (resp. ho nejspis schvalne umele vytvoril), protoze doufa ze znasilni dalsi uzivatele aby z W7 nucene presli na W10...

Ano, psal jste že je to problém na serverech WU. Jenom jste k tomu neuvedl žádnou konkrétní informaci, která by takovou hypotézu podporovala.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 26. 04. 2016, 08:55:16
Ten popisovaný problém s tím že WU nenajde updaty je opravdu způsobený na serveru?

Popisovaný problém je způsobem dementním designem celé té věci, kdy se klient hodiny a hodiny a dny přehrabuje v tom, který update je superseeded a který není. Žádná aktualizace WU klienta to nevyřešila a žádné definitivní řešení to nemá - vyjma kompletního přepsání celé té sračky. Aktuálně problém většinou řeší instalace naprosto s WU klientem nesouvisející aktualizace https://support.microsoft.com/en-us/kb/3145739 (zřejmě proto, že nahrazuje asi tři bambilióny předchozích aktualizací nejrůznějších děr v GDI, čímž se hledání aplikovatelných hotfixů zjednoduší natolik, že se ten křáp na celé dny nezacyklí. Což ovšem neplatí u nově nainstalovaných systémů.

Mimochodem, programátorské schopností Malého Měkkého jsou opravdu úžasné, viz např. http://www.infoworld.com/article/3055885/microsoft-windows/its-time-for-microsoft-to-fix-the-windows-7-update-slowdowns.html

Citace
Called recursively, 20+ layers deep:

wuaueng.dll!CUpdatesToPruneList::AddSupersedenceInfoIfNeeded calls
wuaueng.dll!CUpdateDetectInfoList::FindNewestUpdate calls
wuaueng.dll!CSusMap::_tagMapEntry::_tagMapEntry which finaly calls
ntdll.dll!RtlQueryPerformanceFrequency

"QueryPerformanceFrequency retrieves the frequency of the performance counter. The frequency of the performance counter is fixed at system boot and is consistent across all processors. Therefore, the frequency need only be queried upon application initialization, and the result can be cached." – Microsoft

They called this function about 3,270,000 times during the 2 hour check for updates. Microsoft says "Only call this once, it won't change between boots", Microsoft calls it 3.27 MILLION times.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lael.Ophir 26. 04. 2016, 08:58:58
Zoufalče, vysvětlení, co ten cleanup dělá, máš na tom linku na Technetu. Ten cleanup NEvyčistí žádnou approved aktualizaci. Ani tu, která je superseeded jinou aktualizací.

Pokud je patch nahrazen novým, WSUS ten starý automaticky odmítne (pokud je to nastavené).
https://static.spiceworks.com/shared/post/0006/8211/Capture2.JPG

NEvyčístí ani jedinou schválenou aktualizaci u mezitím odebraného produktu. Nic z toho to nedělá. Desítky a stovky GB hnoje tam budou do doby, než ho přehrabeš ručně.

To je pravda.

Zoufalče...

Pokud chcete slušně diskutovat, nemám nic proti, a i když se snad neshodneme, tak respektuji vás a vaše názory. Jestli ale máte potřebu mě urážet, tak táhněte do hajzlu, vy zamindrákovaný idiote.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 26. 04. 2016, 09:05:03
Pokud je patch nahrazen novým, WSUS ten starý automaticky odmítne (pokud je to nastavené).
https://static.spiceworks.com/shared/post/0006/8211/Capture2.JPG

Ne, ne a NE!!! Revize patche není nový patch. Znova - NE, NE a NE.
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: Lol Phirae 26. 04. 2016, 09:31:11
A abychom si - pro extra natvrdlé jedince z MS - ilustrovali, co to je patch revision:

Kód: [Vybrat]
dism /online /get-packages | findstr KB2952664
Tímto zjistíme, kolik různých revizí backportu šmírovacího zmetka pro W7 (https://support.microsoft.com/en-us/kb/2952664) máme nainstalováno. Aktuálně je KB2952664 na revizi 20.0, na obzvláště postižených strojích budou nainstalovány desítky různých revizí šmírkřápu.

A nyní pozor: Pro jejich odstranění nestačí odinstalovat aktualizaci přes ovládací panely, to odinstaluje pouze poslední revizi. Abychom se toho šmejdu zbavili, tak jedině pěkně ručně:

Kód: [Vybrat]
dism /online /remove-package /PackageName:Package_for_KB2952664~31bf3856ad364e35~amd64~~6.1.3.0
dism /online /remove-package /PackageName:Package_for_KB2952664~31bf3856ad364e35~amd64~~6.1.4.1
dism /online /remove-package /PackageName:Package_for_KB2952664~31bf3856ad364e35~amd64~~6.1.4.4
dism /online /remove-package /PackageName:Package_for_KB2952664~31bf3856ad364e35~amd64~~6.1.5.3
dism /online /remove-package /PackageName:Package_for_KB2952664~31bf3856ad364e35~amd64~~6.1.6.1
dism /online /remove-package /PackageName:Package_for_KB2952664~31bf3856ad364e35~amd64~~6.1.7.4
dism /online /remove-package /PackageName:Package_for_KB2952664~31bf3856ad364e35~amd64~~6.1.8.2
dism /online /remove-package /PackageName:Package_for_KB2952664~31bf3856ad364e35~amd64~~6.1.9.6
dism /online /remove-package /PackageName:Package_for_KB2952664~31bf3856ad364e35~amd64~~6.1.9.8
dism /online /remove-package /PackageName:Package_1_for_KB2952664~31bf3856ad364e35~amd64~~6.1.14.2
dism /online /remove-package /PackageName:Package_1_for_KB2952664~31bf3856ad364e35~amd64~~6.1.9.6
dism /online /remove-package /PackageName:Package_3_for_KB2952664~31bf3856ad364e35~amd64~~6.1.14.2
dism /online /remove-package /PackageName:Package_3_for_KB2952664~31bf3856ad364e35~amd64~~6.1.9.6
dism /online /remove-package /PackageName:Package_for_KB2952664_SP1~31bf3856ad364e35~amd64~~6.1.14.2
dism /online /remove-package /PackageName:Package_for_KB2952664_SP1~31bf3856ad364e35~amd64~~6.1.9.6

Už je to všechno?

Kód: [Vybrat]
PS C:\WINDOWS\system32> Get-HotFix -id KB2952664
Get-HotFix : Cannot find the requested hotfix on the 'localhost' computer. Verify the input and run the command again.
At line:1 char:1
+ Get-HotFix -id KB2952664
+ ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (:) [Get-HotFix], ArgumentException
    + FullyQualifiedErrorId : GetHotFixNoEntriesFound,Microsoft.PowerShell.Commands.GetHotFixCommand

Výborně. Můžeme restartovat a zmetek je konečně skutečně pryč.

Tož takhle "funguje" Maloměk Update, milé děti. Juch!  >:( >:( >:(
Název: Re:MC: pořadí kopírování souborů
Přispěvatel: nobody(ten pravej) 30. 04. 2016, 21:12:19
BFU dostane systém předinstalovaný a opatchovaný, nejvýš si stáhne patche za posledních pár měsíců. Admin by měl umět stáhnout patche.
Ten popisovaný problém s tím že WU nenajde updaty je opravdu způsobený na serveru? Pokud jsem si všiml, tak se to stává jen na některých stanicích.

BFU dostane system co mu vnutej v krame, pokud vyrobce/prodejce "opatchoval" na prelomu prazdnin/podzimu, tak si BFU NESTAHNE zadne patche za poslednich par mesicu, protoze to Microsoft ROZESR&L, to si nepamatujes na co si reagoval?

Ano, psal jste že je to problém na serverech WU. Jenom jste k tomu neuvedl žádnou konkrétní informaci, která by takovou hypotézu podporovala.


Ano problem je zpusoben na WU serverech Microsoftu, kdyz mam totiz 10 ruznych Windows 7 ve virtualu, kde mam snapshot kdy jeste slo dohledat update, snapshot byl vzdy proveden po te co se: zapnout, vyhledat, nainstalovat aktualizace, restart, vyhledat, nainstalovat, restart, vyhledat, nainstalovat, restart, vyhledat,neni co aktualizovat, restart, vyhledat, neni co aktualizovat, vypnout (coz je samo o sobe uchylne, GNU/Linux staci zapnout,vyhledat,nainstalovat,vypnout na totozny cil)
ten obnovenej snapshot uz na zadnem virtualu (ne nedoslo je zmene hw, sw, ani nastaveni) nedokaze aktualizace najednou najit, tak je problem kde? no na stanicich ne, ano je to na serverech WindowsUpdate... a proc? protoze Microsoft znasilnuje uzivatele k prechodu na W10, mam k tomu dukaz? ne, ale jak jina si vysvetlit ze by nechal tolik mesicu tak doprasene aktualizace pro W7 ktere v nejvetsi mire pouzivaji lide co odmitaji (z dobreho duvodu) prejit na posahane W10 ?