[mdk-re] du - странно показывает

Sergey Vlasov =?iso-8859-1?q?vsu_=CE=C1_mivlgu=2Emurom=2Eru?=
Вт Мар 27 11:28:00 MSD 2001


On Tue, 27 Mar 2001 06:19:54 +0400
"Oleg N. Kayunov" <okayunov на mtu-net.ru> wrote:

> denf на novosoft.ru wrote:
> > 
> > 03/26/2001 06:43:26 PM mandrake-russian-admin wrote:
> > >Даю команду:
> > > du --max-depth=1 -k
> > >в некоем каталоге, получаю суммарный объем:
> > >351792
> > >Копирую каталог на другой диск (HDD, CD-R),
> > >даю в точности ту же команду, получаю суммарное число:
> > >482280
> > >
> > >Причем, когда смотрю в конкретные оглавления, на размеры файлов, то
> > >вижу, что вторая (большая) цифра явно ближе к истине.
> > >Причем разница иногда более чем двукратная 8-[]
> > >
> > >Пример:
> > >Для некоего оглавления в оригинальном местоположении команда показывает
> > >116, в скопированном месте 315, а в оглавлении наличествуют два файла
> > >объемами:
> > >278528 и 39725 (уже байтов).
> > >Явно 315 (килобайт) ближе к истине.
> > >
> > >И как это понимать?
> > 
> > очевидно, при копировании линки копируются как файлы
> Так ведь нет же: в том примере всего ДВА файла и ни один не есть линк!
> Ради интереса проверил всё исходное оглавление, нашел один симлинк, да и
> тот не работающий (из-за давних переименований) - все таки польза!
> 
> А исходный вопрос остается - даже при отсутствии линков показания du
> расходятся.
> 
> Такое впечатление, что в исходном оглавлении файлы прозрачно
> заархивированы.
> Теоретически в ext2fs сие, вроде бы, возможно, я даже попробовал lsattr
> -ru, но она на меня обиделась, заявив, что can't compute и
> Inappropriative ...

В принципе сжатие на ext2fs возможно (патч e2compr), но я им никогда не пользовался (в свое время меня так достал глючный DoubleSpace, что теперь все подобные вещи вызывают у меня как минимум подозрение в глючности).

А еще даже на обычном ext2 могут быть файлы с дырами (sparse files). Практически все утилиты при копировании таких файлов разворачивают их. У GNU tar есть ключ -S (--sparse), в документации авторы рекомендуют его использовать при резервном копировании.

> > 1╘щ╜╘╝К,┴╘Фj)b·        b╡с²зз▒ЙН╡х ²╘m√)Нф╩║╤зЩ╘m√)Нф╩©≥╗╔≥╘Ъ√+-┼wХЧf╖v╤╓z╩╛╡&╖
> Кстати, а это как понимать? В смысле - прочесть?

Stuphead не одинок :-)

Исходное письмо было послано в base64 (да еще чем - Lotus Notes Release 5.0.6). Менеджер рассылки присобачил к нему стандартный хвост, не заметив base64. После чего Netscape попытался раскодировать этот хвост как base64 и получил... сами видите что.




Подробная информация о списке рассылки community