Dotaz: HDD ztracené místo na disku

[Stewa]

Nedávno došlo vypnutím disku k ztrátě cca 200GB dat s tím, že soubory na disku nejsou, ale místo stále zabírají. Jakým příkazem je možné navrátit disku ztracený prostor?

HW: Asus Router WL500gP HDD Maxtor USB

SW: Firmware Oleg IPKG package

Odpovědi

[NN]

Ja bych se podival do /lost+found.. (pripadne az po fsck).

NN

[Stewa]

Ztracene soubory jsou nenavratne pryc, proste na disku nejsou. Uz je ani nechci obnovit, jde mi o nastaveni puvodni kapacity disku. A nejlepe jinak nez sformatovanim.

[Heron]

Radí vám dobře. fsck a pak si to klidně s lost+found smažte.

[Stewa]

fsck jsem samozřejmě spustil a našel spoustu chyb, Vše opravil a úspěšně se ukončil. Problém je ale stále stejný - Linux ukazuje, že disk je zaplněn z 98% přitom velikost všech souborů je sotva 50% !!! Adresář "Lost+found" na disku nikde není, takže ani jeho obsah nemůžu najít. Na jiných discích tento adresář je.

Co s tím můžu dělat???

[Filip Jirsák]

Nikde nepíšete, jak tu velikost zjišťujete. Nejlepší bude, když sem dáte výpis df a du -cx pro příslušný oddíl.

[Stewa]

Disk je 640GB, zformátovaný na 58OGB. df hlásí /dev/discs/disc1/part1 608797468 565404444 12467904 98% /opt/maxtor Midnight commander po příkazu sečtení velikosti dat na oddíle hlásí obsazení 300GB; Total commander (přístup přes sambu) hlásí 12GB volného místa. Celkově to vypadá, že na oddíle je někde schovaných 280GB dat, které nejsou vidět

[Filip Jirsák]

A výstup du -ckx /opt/maxtor?

[Filip Jirsák]

Respektive

du -sckx /opt/maxtor

Zjišťování, ve kterém adresáři jsou ty velké soubory si můžeme nechat na později.

[Stewa]

Děkuji za ochotu a snahu, nicméně opět opakuji, že ty soubory linux nevidí! Příkaz "du" najde právě těch cca 300GB dat. Dalších 280GB nikde není vidět, ani při výpisu velikostí všech souborů na disku (du -ckx /opt/maxtor), které dává součet 300GB, nikoli cca 580GB, jak uvádí příkaz "df".

[Filip Jirsák]

Termíny jako „linux nevidí“, „součet v Midnight Commanderu“ nebo „součet v Total Commanderu přes Sambu“ mohou znamenat cokoli. Proto jsem se ptal na přesnou hodnotu obsazeného místa, kterou zjistíte právě tím příkazem du. Ono odhadovat na základě jedné věty dotazu, o jaký jde problém, není zrovna nejjednodušší, a pokud tazatel tvrdošíjně odmítá poskytnout další informace, je to ještě těžší.

Pokud je to ext2 nebo ext3, nepřenastavil se vám počet rezervovaných bloků? Jejich počet zjistíte příkazem tune2fs -l /dev/discs/disc1/part1. Jinak bych zkusil disk ještě jednou odmountovat a projet fsck, pak přimountovat v read-only režimu a znova zkontrolovat velikosti. Pokud by pořád neseděly, bude chyba buď v kódu souborového systému, nebo vadný disk.

[Stewa]

Výsledek příkazu du -sckx /opt/maxtor a du -ckx /opt/maxtor jsou k dispozici zde a zde (cca 400kB txt soubor). Příkaz tune2fs linux vůbec neobsahuje, musel bych ho nějak stáhnout a zkompilovat - pokud bude potřeba tak to udělám. Zkusím teď umount a mount v readonly. Potíže s volným místem nastaly již dříve.

[Filip Jirsák]

Jaký je na tom disku souborový systém? Pokud používáte ext2/3, měl byste mít nainstalované příslušné utility, kde by tune2fs mělo být.

Obsah disku jste zveřejňovat nemusel a klidně ten druhý soubor ze serveru smažte. du -sckx /opt/maxtor stačí, to chybějící -s jsem v následujícím komentáři doplňoval, protože jsem na něj jen zapomněl. Bez toho -s by to bylo užitečné pro vás, pokud by skutečně někde byly skryté soubory, které by to místo zabíraly.

Ještě mne napadá, pokud je to ext3, mountujete to vždy jako ext3, ne jako ext2? Nevím, zda by to šlo bez nějakých protestů mount, ale napadlo mne, zda by tu chybějící kapacitu nemohl způsobovat třeba žurnál. I když je divné, že by byl tak velký.

Každopádně když disk přimountujete jako read-only, neměl by na něm žádný program držet v paměti odkaz na již smazaný soubor.

[Stewa]

Ano, jedna se o ext3, mountuje se přes fstab jako ext3 partition. tune2fs jsem našel, jsou součástí balíku e2fsprogs (ipkg install e2fsprogs). moun jako read only (mount -r) nepomáhá, výsledek stále stejný, jen příkaz tune2fs -m 1 /dev/disc.... vysvobodil několik dalších GB.

[Filip Jirsák]

Zkuste na tom disku (buď odmountovaném nebo v read-only režimu) spustit ještě jednou fsck.ext3 -f – pokud to chybějící místo není ani v datech ani v rezervované oblasti, nenapadá mne nic jiného, než že je souborový systém poškozen.

[Stewa]

V žádném případě jsem Vás nechtěl žádným způsobem urazit, jen jsem nechtěl zveřejňovat obsah soukromého disku. Za terminologii se omlouvám, píšu to tak, jak to dělám -> Midnight commander, najedu na přimountovaný oddíl /opt/maxtor/ a z COMMANDS vyberu CHECK DIRECTORY SIZES - chvilku disk chroustá (cca 5 minut) a vyplivne stejnou velikost jako příkaz du. Co se týče Total commandera: disk mám připojený přes sambu a při připojení k adresáři mi ukazuje total commander 11GB volného z 580GB.

[Šangala]

Poznámka (nevím jestli k něčemu):
Je to lost+found ne Lost+found standardně dostupné jen pod root-em.
Tudíž příkaz du -schx /opt/maxtor musí být provedeno pod root-em

[ZAH]

Asi blbost, ale přesto zkontroloval jste rezervu pro roota ? Standartně do deseti procent.

[impact]

Pomocou tune2fs skus zmenit pocet rezervovanych blokov na 1%.

tune2fs -m 1 /dev/sdxy

Zdroj

[Stewa]

Wow, ano, toto pomohlo o cca dalsi 8GB, nicmene porad je kdesi dalsich vice jak 200GB

[ZAH]

Takže ještě tu nepadlo. Něco je namountováno do adresáře, který není prázdný (spíše je boubelatý). Co vypíše příkaz mount a poté zkusit případně podezřelé odmountovat a prověřit znova.

[Filip Jirsák]

Soubory z původního adresáře se ale do obsazené velikosti nepočítají, nijak se k nim nedostanete. Leda by se používal skládaný souborový systém – to by je ale zase správci souborů nebo du bez parametru -x započítali.

[Skokan, Pavel]

nesouhlasim s tim, ze soubory vymaskovane namountovanim do neprazdneho adresare se do celkoveho mista nezapocitavaji a radeji jsem si to experimentalne overil...

Souborový systém      1K bloků   Použité     Volné Uži% Mounted on

#PUVODNI STAV
/dev/sda2            348682348  13371596 317598688   5% /


#VYROBENO /mnt/tst A ZAPLNENO VICE NEZ 40 GB DAT
/dev/sda2            348682348  58056840 272913444  18% /


#ZAMASKOVANO /mnt/tst PRIMOUNTOVANIM INSTALACNIHO DVD
/dev/sda2            348682348  58056940 272913344  18% /
/dev/sr0               3129324   3129324         0 100% /mnt/tst

[Filip Jirsák]

Experimentálně jste si ověřil, že nemáte pravdu. Alespoň já u /mnt/test vidím volné místo 0, což odpovídá „volnému místu“ na DVD, volné místo na /dev/sda2 se do toho nezapočítává. Kdybyste si nechal spočítat velikost obsazeného místa v /mnt/tst, opět získáte velikost souborů na DVD, ale ne soubory, které jsou v adresáři /mnt/tst na oddíle /dev/sda2 – ty jsou momentálně pro systém nedostupné.

Je pravda, že pokud by původní tazatel měl někde do zmíněné složky přimountován další oddíl, který by skryl soubory uložené na tom oddíle „pod ním“, vykazovalo by to popisované chování – prázdného místa by bylo méně, protože by z něj ukusovaly i soubory schované pod nově přimountovaným souborovým systémem. Předpokládám ale, že by nám tazatel prozradil, že do nějakého podadresáře má přimountován ještě jiný souborový systém, navíc při rozcvičkách s přimountováním a odmountováním by jej musel také odmountovat.

[Filip Jirsák]

Aha, teď jsem si to přečetl znova, a asi jsem ten váš první příspěvek nepochopil. Chápal jsem to tak, že podle vás je /opt/maxtor neprázdný v oddíle, který je namapován na / nebo /opt. Vy jste asi myslel naopak to, že někde v adresáři třeba /opt/maxtor/tmp je namountován další oddíl, který skryje data na tom disku, který má „ztracenou“ kapacitu. Pak myslíme oba to samé.

[Skokan, Pavel]

Ja myslim, ze na to koukame z ruznych uhlu pohledu a pravdu mame oba, protoze nikdo z nas neupresnil, jak to vlastne mysli.

Slo mi o zapocitani souboru do / filesystemu i kdyz jsou nedostupne kvuli "zamaskovani" primountovanim neceho do neprazdneho adresare...

[Stewa]

Tak to vypadá, že se konečně dostáváme k jádru problému. fsck.ext3 na umountovane partition po pár hodinách nahodila hlasku fsck.ext3: Memory allocation failed while retrying to read bitmaps for

Podrobnejsi vypis:

50209699 50209700 50209701 50209702 50209703 50206673 50209705 50209706 50209707 50209708 50209709 50209710 50209711 50209712 50209713 50209714 50209715 50209716 50209717 50209718 50209719 50206681 50209721 50209722 50209723 50209724 50209725 50209726 50209727 50209728 50209729 50209730 50209731 50209732 50209733 50209734 50209735 50206689 50209737 50209738 50209739 50209740 50209741 50209742 50209743 50209744 50209745 50209746 50209747 50209748 50209749 50209750 50209751 50206697 50209753 50209754 50209755 50209756 50209757 50209758 50209759 50209760 50209761 50209762 50209763 50209764 50209765 50209766 50209767 50206705 50209769 50209770 50209771 50209772 50209773 50209774 50209775 50209776 50209777 50209778 50209779 50209780 50209781 50209782 50209783 50206713 50209785 50209786 50209787 50209788 50209789 50209790 50209791 50209792 50209793 50209794 50209795 50209796 50206721 50209797 50209798 50209799 50206722 50209801 50209802 50209803 50209804 50209805 50209806 50209807 50209808 50209809 50209810 50209811 50209812 50209813 50209814 50209815 50206729 50209817 50209818 50209819 50209820 50209821 50209822 50209823 50209824 50209825 50209826 50209827 50209828 50209829 50209830 50209831 50206737 50209833 50209834 50209835 50209836 50209837 50209838 50209839 50209840 50209841 50209842 50209843 50209844 50209845 50209846 50209847 50206745 50209849 50209850 50209851 50209852 50209853 50209854 50209855 50209856 50209857 50209858 50209859 50209860 50209861 50209862 50209863 50206753 50209865 50209866 50209867 50209868 50209869 50209870 50209871 50209872 50209873 50209874 50209875 50209876 50209877 50209878 50209879 50206761 50209881 50209882 50209883 50209884 50209885 50209886 50209887 50209888 50209889 50209890 50209891 50209892 50209893 50209894 50209895 50206769 50209897 50209898 50209899 50209900 50209901 50209902 50209903 50209904 50209905 50209906 50209907 50209908 50209909 50209910 50209911 50206777 50209913 50209914 50209915 50209916 50209917 50209918 50209919 50209920 50209921 50209922 50209923 50209924 50209925 50209926 50209927 50206785 50209929 50209930 50209931 50209932 50209933 50209934 50209935 50209936 50209937 50209938 50209939 50209940 50209941 50209942 50209943 50206793 50209945 50209946 50209947 50209948 50209949 50209950 50209951 50209952 50209953 50209954 50209955 50209956 50209957 50209958 50209959 50206801 50209961 50209962 50209963 50209964 50209965 50209966 50209967 50209968 50209969 50209970 50209971 50209972 50209973 50209974 50209975 50206809 50209977 50209978 50209979 50209980 50209981 50209982 50209983 50209984 50209985 50209986 50209987 50209988 50209989 50209990 50209991 50206817 50209993 50209994 50209995 50209996 50209997 50209998 50209999 50210000 50210001 50210002 50210003 50210004 50210005 50210006 50210007 50206825 50210009 50210010 50210011 50210012 50210013 50210014 50210015 50210016 50210017 50210018 50210019 50210020 50210021 50210022 50210023 50206833 50210025 50210026 50210027 50210028 50210029 50210030 50210031 50210032 50210033 50210034 50210035 50210036 50210037 50210038 50210039 50206841 50206842 50206843 50206844 50206845 50206846 50206847 50206848 50206850 50206851 50206852 50206853 50206854 50206855 50206856 50206858 50206849 50210041 50210042 50210043 50210044 50210045 50210046 50210047 50210048 50210049 50210050 50210051 50210052 50210053 50210054 50210055 50206857 50210057 50210058 50210059 50210060 50210061 50210062 50210063 50210064 50210065 50210066 50210067 50210068 50210069 50210070 50210071 50210073 50210074 50210075 50210076 50210077 50210078 50210079 50210080 50210081 50210082 50210083 50210084 50210085 50210086 50210087 50210089 50210090 50210091 50210092 50210093 50210094 50210095 50210096 50210097 50210098 50210099 50210100 50210101 50210102 50210103 50210105 50210106 50210107 50210108 50210109 50210110 50210111 50210112 50210113 50210114 50210115 50210116 50210117 50210118 50210119 50210121 50210122 50210123 50210124 50210125 50210126 50210127 50210128 50210129 50210130 50210131 50210132 50210133 50210134 50210135 50210137 50210138 50210139 50210140 50210141 50210142 50210143 50210144 50210145 50210146 50210147 50210148 50210149 50210150 50210151 50207376 50210153 50210154 50210155 50210156 50210157 50210158 50210159 50210160 50210161 50210162 50210163 50210164 50210165 50210166 50210167 50210169 50210170 50210171 50210172 50210173 50210174 50210175 50210176 50210177 50210178 50210179 50210180 50210181 50210182 50210183 50210185 50210186 50210187 50210188 50210189 50210190 50210191 50210192 50210193 50210194 50210195 50210196 50210197 50210198 50210199 50210201 50210202 50210203 50210204 50210205 50210206 50210207 50210208 50210209 50210210 50210211 50210212 50210213 50210214 50210215 50210217 50210218 50210219 50210220 50210221 50210222 50210223 50210224 50210225 50210226 50210227 50210228 50210229 50210230 50210231 50210233 50210234 50210235 50210236 50210237 50210238 Multiply-claimed block(s) in inode 33849354: 85157248 85157257 85157258 85157259 85157260 85157261 85157262 85157263 85157264 85157265 85157266 85157267 85157268 85157269 85157270 85157271 131141538 Multiply-claimed block(s) in inode 42565634: 85157248 85157257 85157258 85157259 85157260 85157264 85157265 85157266 85157267 85157268 85157269 85157270 Pass 1C: Scanning directories for inodes with multiply-claimed blocks Pass 1D: Reconciling multiply-claimed blocks fsck.ext3: Memory allocation failed while retrying to read bitmaps for /dev/discs/disc1/part1 e2fsck: aborted

Při první kontrole jsem si tohoto varování nevšiml, nebo se neobjevilo.

[Ondar]

Google it!

[Stewa]

To se ti řekne, ale nic kloudného jsem na internetu nenašel