ciekawostka przyrodnicza: na serwerze kończy się miejsce na dysq. sprawdzam wielkość dysq – 33GB, sprawdzam zajętość katalogów przy pomocy explorera – wychodzi koło 16GB. ilość wolnego miejsca na dysq – bliska 0. o co c’mon?
jeszcze ciekawiej: dokładnie taka sama sytuacja jest na drugim dysq w tym serwerze. wychodzi na to, że zniknęło ok 4o%-5o% wszystkich dysqw – nie wiadomo gdzie i jak.
w pierwszej kolejności zadzwoniłem i zamówiłem nowe dyski do serwera. w między czasie trzeba sprawdzić o-co-cho.
dochodzenie
zacząłem od dość brzydkiej operacji – nadawania uprawnień do ‘zakazanych’ katalogów – system volume information, recycle bin i wszelkie inne systemówki, do których nie ma uprawnień a więc na pewno zostały wkalqlowane w sumaryczną wielkość. wszystkie miały pomijalną wielkość. to, czego się przy okazji dowiedziałem to to, że system sobie potem ładnie te katalogi ‘reperuje’ przywracając im po jakimś czasie [restart?] uprawnienia. ufff… przynajmniej sie nie rozjechał (;
kolejny strzał – shadow copy lub restore points. w w2k8 (R2) nie ma dostępnej opcji/zakładki Restore Points. próbowałem na siłę sprawdzić korzystając z rozwiązania z http://www.win2008workstation.com/forum/viewtopic.php?p=4301#p4301. zakładka pojawia się co prawda – ale wywala się z błędem. niemniej można to sprawdzić nieco bardziej ‘legalnie’:
ponieważ restore point jest ‘migawką’ shadow copy – powinien być zapis o niej w systemie. w związku z tym powinno dać się to sprawdzić przy pomocy vssadmin
PS C:> vssadmin.exe list shadows
vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.
No items found that satisfy the query.
pupa. nie muszę w związq z tym dodawać, że sama funkcjonalność previous versions jest wyłączona. zaczynam zabawę z alternatywnym badaniem wielkości katalogów – czyli powershell. znalazłem fajny art krok-po-kroq wyjaśniający jak do tego podjeść. nie jest miłe i tak proste, jak bym się tego spodziewał – ale działa (: no i kilka fajnych tipsów PS przyda się na przyszłość:
"{0:N2}" -f ((Get-ChildItem ’.program files (x86)’ -recurse | Measure-Object -Property length -sum).sum / 1GB ) +" GB"
nie bez powodu pokazuję od razu ten katalog – ponieważ to właśnie on okazał się być złodziejem przestrzeni. jeszcze troszkę bardziej rozbudowana składnia do reqrencyjnego odpytania i jest winny!
PS C:Program Files (x86)> get-childitem | %{"$_ size: "+ "{0:N2}" -f ((Get-ChildItem $_ -recurse | Measure-Object -Property length -sum).sum / 1GB )+" GB"}
[…]
Microsoft Configuration Manager size: 18,32 GB
[…]
explorer pokazuje dla tego katalogu znaczną różnicę w wielkości: 0B (słownie – zero bajtów). na drugim dysq sprawca jest ten sam – repozytorium SCCM i katalog SMSPKG.
dyski właśnie przyszły – a więc czas na kolejne hardtesty – jak przerzucić cały system na nowe dyski. spróbuję windows backup…
**UPDATED**
pozostaje pytanie – czemu explorer nie pokazuje wielkości niektórych katalogów. i tutaj odpowiedzią jest moja najulubieńsza, taka jej mać, funkcja – UAC. ma to związek ze starszym wpisem. ktoś mógłby stwierdzić, że to nie wina UAC tylko explorera – którego nie da się [normalnie] odpalić z tokenem administratora. powershell potrafił zliczyć wielkości, ponieważ był właśnie z nim uruchomiony. prawie na pewno – gdybym zamiast explodera używał jakiegoś menadżera plików firmy trzeciej – również zliczyłby katalogi prawidło. imho jednak takie rzeczy stanowią integralną część systemu i powinny być przemyślane w całości – jako spójna platforma. no nic – po prostu dodaję nową zasadę: “nie używaj explorera na serwerze z UAC”.
druga kwestia – jeszcze do zbadania – to z jakiej racji SCCM tak pożarł miejsce.
eN.
D3LLF