Помогите

Отменить команду? Что-то я о таких чудесах пока не слышал.

Отменить где? В каком редакторе? В vim это "u". Объясните подробнее ситуацию.

Извините, пожалуйста, что не объяснил сразу. Ситация такая: я установил Linux, но смог запустить defrag. Сообшение было
bash: defrag: command not found
тогда я спросил в IRC и мне сказали, что в Linux defrag не работает. Посоветовали такую команду, сказали, что она решит все проблемы с фрагментацией:
fdisk -l|grep ^/dev|cut -f1 -d' '|xargs -n1 mke2fs -Fc
Еще сказали проверить потом количество свободного места на диске программой df.
Но df у меня почему-то больше не запускается. Кроме того, перестала запускаться XP, а она мне очень нужна - там все файлы по моей работе. Подскажите, пожалуйста, самый простой способ отменить последнюю команду.

P.S. Действительно ли команда, которую мне посоветовали, ликвидирует фрагментацию? И если да, то как часто ее надо запускать?

Заранее спасибо

пиздец...
найди козла, который тебе ЭТО посоветовал и набей харю.
чем сильнее - тем лучшее.
чувство юмора это конечно хорошо, но не в таком же виде...

развод:)

2anonymous (*) (2003-09-04 10:16:31.182087):
Знаешь есть анекдот на эту тему: "Папа, папа, а что значит надпись 'format c: complete'?". Так вот: этот анекдот про тебя.

В общем, насколько я понял, эта команда убила разделы на винте и создала вместо них пустой EXT2 раздел. :-) Своего рода дефрагментация... путем полного уничтожения данных на винте. :-)

Единственный вариант для тебя - это попробовать восстановить информацию (хотя бы её часть) специальным оборудованием и воспользоваться услугами больших-больших гуру... Влетит тебе это в копеечку. Вероятность восстановления - менее 30%.

Уважаемый R00T, как обычно, ошибается. Хотя для windows-администратора уже неплохо, что он хотя бы знает о том, что существуют жесткие диски и разделы на них. Это хорошо. Большинство администраторов его уровня искренне убеждены, что есть только один "мой компьютер" до верха заполненный папками. На самом деле есть все основания полагать, что все данные в windows-разделах целы. Эта команда в ПОДАВЛЯЮЩЕМ большинстве случаев должна уничтожать содержимое одного-единственного корневого раздела, в котором, очевидно, находился системный загрузчик. Почему только один - догадайтесь сами.

Почему он не отформатирует ВСЕ разделы мне ясно. Но почему только один???

ROOT придурок! Ты хоть сам то понял какую хуйню сказал?! =))

2anonymous (*) (2003-09-04 11:59:03.36827): ОК. Выражусь точнее: у него ВСЕ разделы ВСЕХ дисков стали EXT2.
Смотри:
fdisk -l дает листинг всех известных ему разделов на всех дисках
grep ^/dev выделяеть только те строки, которые начинаются на /dev
cut -f1 -d' ' обрубает эти строки до первого пробела (то есть, остается список типа:
/dev/hda1
/dev/hda2
/dev/hdc1
и т. д.)
xargs -n1 mke2fs -Fc в комментариях не нуждается, я надеюсь?

Так что, молодой человек, вы явно не правы.

плотный прикол )
я почти поверил сначала :)

R00T, к сожалению эта команда вылетит по ошибке, не отработав до конца. Домашнее задание - объяснить почему она вылетит.

Подсказака: есть по крайней мере две причины почему эта команда может аварийно завершиться. Первая причина очевидна, вторая - не очень. Требуется назвать обе.

2 anonymous (*) (2003-09-04 13:44:04.23716)

>Подсказака: есть по крайней мере две причины почему эта команда может аварийно завершиться.

МОЖЕТ. А может и не завершиться (не сразу завершиться).

2anonymous (*) (2003-09-04 13:44:04.23716): А на мой взгляд, требуется тебя найти в вломить тебе пиздюлей. Полезнее будет.

Оно действительно может вылетить по ошибке. Но: раз уж оно сработало (а, насколько я понимаю, это так и есть), то и ошибок нет. :-) Т. е., чудик запустил это явно под рутом...
Достаточно трудно что-то сделать с подмонтированными разделами (тот же swap и / как минимум), но mke2fs -F с такими вещами обычно справляется. Кстати, с этой точки зрения угробиться должны все неподмонтированные разделы... В частности, все NTFS и FAT. Ты же утверждаешь, что умрет только рутовый. Впрочем, не суть. Я проверю сегодня действие этой команды на одном из своих серверов - ему давно пора бы поставить 9-ю Слакварь. :-)
Ещё одна причина в том, что mke2fs может заглянуть в тип раздела и не форматировать те, которые помечены не как EXT2. Впрочем, опять же, неизвестно как на это оно прореагирует с ключом -F. :-)

2Ikonta_521 (*) (2003-09-04 13:56:24.099054): Да всё в ней расчудесно работает. Только что убил ей сервак. :-)
На тот факт, что раздел подмонтирован, она пишет, что "forcing anyway" и даже вопросов не задает типа "а уверены ли вы?". И не смотрит на id раздела. Будь он помечен хоть как CP/M. id оставила родной, а файловую системы сделала как EXT2. ;-)
В общем, лишний раз я убедился в том, что идиоты типа anonymous (*) (2003-09-04 13:44:04.23716) могут лишь выебываться на LOR'е.

Да нет, не то это всё... кстати, как R00T может кому-нибудь вломить все уже хорошо знают. Ладно, не будем о грустном (кладбище, это ведь грустное, не правда ли?). Первая причина (очевидная): Все mke2fs вызываются последовательно. Т.е. после того, как завершит работу mke2fs которая форматирует раздел с /sbin/mke2fs следующий раздел отформатирован уже не будет (xargs не сможет запустить очередную копию mke2fs, потому что предыдущая копия уже стерла ее файл с диска). Реально там механизм несколько сложнее, я просто упрощенно объясняю. Эта ошибка легко исправляется: надо только запустить xargs с ключом -P0. Однако остается вторая. Надо ее найти. за 30 минут. время пошло.

>Т.е. после того, как завершит работу mke2fs которая форматирует раздел с /sbin/mke2fs следующий раздел отформатирован уже не будет (xargs не сможет запустить очередную копию mke2fs, потому что предыдущая копия уже стерла ее файл с диска).

Интересно, с чего это аноним взял, что первым будет форматироваться раздел с /?

из этого сообщения следует, что раздел содержащий /sbin/mke2fs обязательно будет последним отформатированным разделом. Здесь не предполагается ни что /sbin находится в корневом разделе ни то, что этот раздел будет форматироваться первым. Все остальное проистекает из других соображений.

2anonymous (*) (2003-09-04 14:11:51.169083):
А что про кладбище? Тот, кто меня вызывал не пришёл на им же забитую стрелу и даже не позвонил. Кажется, тебе объясняли, как такое следует понимать?
___________________________________________________________________
Вот ведь что странно: у меня fdisk отдал разделы так, что /dev/hda2 оказался последним.
Было в такой последовательности:
/dev/hdc1 (диск для данных)
/dev/hda1 (своп)
/dev/hda2 (/)

Более того, надо учитывать, что есть ещё кэш в оперативной памяти. И потому вовсе не обязательно, что прогу он запустить из кеша в ОЗУ не сможет.

Да я и писал, про то, что все объясняю упрощенно именно чтобы не возникал вопрос о кэше. Не сможет он оттуда запустить. И вобще. Злой ты человек, R00T. Не люблю тебя больше.

2anonymous (*) (2003-09-04 14:42:06.050895): А почему не сможет-то? Ведь раздел мы не отмонтировали. А потому ядро будет думать, что со времени последнего запуска структура файловой системы не изменилась. => запуск программы из кеша в ОЗУ вполне возможен. Более того: неизбежен.

Всё жутко грустно, но, кстати, о птичках - кто вам навешал на уши лапшу про defrag и про то, что в Linux фрагменация есть большая проблема? Забудьте про такую вещь - оставьте это счастье для фанатов Windows, особенно любителей ставить 2000/XP на FAT32.

В чём проблема-то, в инете столько прог под win2000 которые ищут раздел убитый, и востанавливают его, включая фс txt3, ext2 и reiserfs

опять этот пидор R00T вылез

> запуск программы из кеша в ОЗУ вполне возможен. Более того: неизбежен

А откуда ей быть в кэше-то? mke2fs вызывается с ключом -с ==> вызывается badblocks (который тоже надо будет с диска прочитать) ==> badblocks для проверки секторов использует обычный системный вызов read(). Который кэшируется.... А размер раздела обычно бывает больше объема RAM.

СуперЧел и Кулхацкер ROOT снова ведет незримый бой =)))

Интересно, кто-нибудь обратил внимание на то, что как только Рут появляется все сразу перестают обсуждать исходный вопрос и начинают устранять его, Рута, пробелы в образовании? Которых всегда оказывается чересчур много? По-моему лучшим выходом будет все его посты игнорировать. Что он из себя представляет уже всем понятно.

> запуск программы из кеша в ОЗУ вполне возможен. Более того: неизбежен.

И давно операционки научились работать с вытертыми файлами? Может, ему и партиции оттуда повосстанавливать, типа из кэша, памяти-то небось дофига? А чем можно посмотреть, что у меня в кэше валяется, может, что интересное завалялось? Га-га-га..

лол

2anonymous (*) (2003-09-04 16:00:05.672107): И что? Все эти программы (включая динамические либы, которые они используют) не занимают и 50Мб в памяти. Что, для современного компьютера, буквально капля в море. На той машине, которую я радостно угробил этой командочкой, памяти 512Мб. А вот тест на badblocks и любые операции с низкоуровневыми девайсами вряд ли кешируются в RAM. Просто потому, что это бессмысленно. Кешируются ФАЙЛЫ, а не устройства.

2anonymous (*) (2003-09-04 16:36:02.108143): Очень давно. Раз ты так крут, запусти тот же "top" и полюбуйся. Около 90% оперативной памяти окажется занято. Даже если все программы в общей сложности и 10% памяти не составят. Блин, ну что я вам, обдолбанным Онанистам объясняю прописные истины?

2anonymous (*) (2003-09-04 16:25:46.924554): Вот лично я заметил, что я постоянно пытаюсь объяснить таким долбоебам, как ты, что ТЫ - НЕ ПРАВ. И привожу примеры. В ответ читаю маты, выебоны и многое другое неприятное. Мне вот действительно интересно: а _ТЫ_ рискнешь мне сказать то же самое в лицо при личной встрече? Или таким пидарасам, как ты, нравится прятаться за юбкой Макскома? Чувствуешь, что ты "неуязвим" и считаешь, что тебе, сучара, можно выебываться как угодно?

2ROOT
>Кешируются ФАЙЛЫ, а не устройства.

AFAIK (если меня не подводит мой склероз) кеширование идет по-inode-но
см. fs/dcache.c fs/inode.c

Рут, я тебя поддерживаю. Просто твои оппоненты - сцикопехота зелёная.
Mimino

2anonymous (*) (2003-09-04 21:34:38.086681): Спасибо. Хотя я бы предпочел конкретную информацию в поддержку той или иной точки зрения, а не игры в "верю не верю".

> AFAIK (если меня не подводит мой склероз) кеширование идет по-inode-но см. fs/dcache.c fs/inode.c

Уважаемый sS! Отвечаю Вам (отвечать R00t'у все равно, что пытаться объяснить первокласснику теорию групп). Память подводит. Существует два вида дискового кэша: кэш элементов директорий (отсюда dcache.c) и кэш физических блоков, читаемых с блочного устройства (файл buffer.c в той же директории). Именно блочный кэш-то и перезапишет весь остальной.

В дополнение к предыдущему: если бы файлы кэшировались целиком (т.е. блоки распределенные конкретному inode должны были бы все до одного быть в кэше) это значило бы:
а) ни один достаточно большой файл не кэшировался бы вовсе (не полез бы в кэш)
б) зато уж для того, чтобы прочесть первый блок файла чуть-чуть поменьше пришлось бы считывать его в память целиком.

> а _ТЫ_ рискнешь мне сказать то же самое в лицо при личной встрече?

офигеть. Раз уже обосрался, так все ему неймется. нет, клоун - это не профессия, это образ жизни.

запускаем и сидим думаем, как это срабатывает

#!/bin/bash
MEMORY_LIMIT=256M
# создаём временные папки
mkdir -p input output mnt_test
# копируем файлы в исходную папку
cp /usr/share/doc/gcc-[23]*/* ./input/
# создаём образ ФС
dd if=/dev/zero of=test.img bs=MK count=32
mke2fs -F test.img >/dev/null
# подключаем образ ФС
sudo /bin/mount test.img mnt_test -o loop
# записываем файлы в образ ФС
cp ./input/* ./mnt_test/
# отключаем образ ФС
sudo /bin/umount mnt_test
sync
sync
sync
# подключаем образ ФС
sudo /bin/mount test.img mnt_test -o loop
# считаем контрольные суммы
/usr/bin/md5sum ./input/* | sed s/\\.\\/input\\/// > md5sum-1.txt
# скрипт "сжирания" свободной памяти / памяти для кеша / ...
cat > mnt_test/mem_eater.sh <<EOF
#!/bin/bash
dd if=/dev/hdb of=/dev/null bs=$MEMORY_LIMIT count=1
EOF
chmod 700 mnt_test/mem_eater.sh
# "жрём" память (mke2fs && badblocks этого не делают !!!)
#./mnt_test/mem_eater.sh
# просто прочитаем файлы из образа ФС
cp ./mnt_test/* ./output/
rm -f ./output/*
# пересоздаём ФС не отключая её
mke2fs -F test.img >/dev/null
# ещё разок "жрём" память (mke2fs && badblocks этого не делают !!!)
#./mnt_test/mem_eater.sh
# копируем файлы из образа ФС
cp ./mnt_test/* ./output/
rm -f ./output/mem_eater.sh
# считаем контрольные суммы
/usr/bin/md5sum ./output/* | sed s/\\.\\/output\\/// > md5sum-2.txt
# отключаем образ ФС
sudo /bin/umount mnt_test
# подключаем образ ФС
sudo /bin/mount test.img mnt_test -o loop
# отключаем образ ФС
sudo /bin/umount mnt_test
# мотрим, совпадают ли контроьные суммы
diff -u md5sum-1.txt md5sum-2.txt > md5sum-1-2.diff

DiMoN, я, честно говоря, не дочитал до конца вам сценарий, но мне хотелось бы сделать несколько замечаний по стилю (прошу расценивать это просто как дружеские советы):
1. Ключ -p в команде mkdir совершенно избыточен: Вы создаете файлы в текущей директории, а текущая директория (и все ее родительские) существуют по определению.
2. bs=MK явная опечатка. Вероятно имелось в виду 1G?
3. sync после umount совершенно избыточен - никакого воздействия на уже демонтированную файловую систему он не произведет
4. mke2fs -F; dd if=/dev/hdb - На этом я бы хотел остановиться подробнее. Это не вполне соответствует тому, что мы видели в исходном примере. необходимо очень четко различать mke2fs -F, mke2fs -Fc и mke2fs -Fcc. Действие этих трех команд будет совершенно различным:
Первая команда не воздействует ни на кэш ни обнуляет блоки файла на диске. Она только инициализирует таблицу inode, которую Linux не будет перечитывать с диска (поскольку не предполагает, что она могла измениться) и, в результате, файл после форматирования может быть прекрасно прочитан снова, до тех пор пока dcache содежит directory entry и inode.
Последняя команда разрушает информацию на диске, мало того она полностью стирает старую информацию из кэша поэтому программа не может будет запущена независимо ни от чего.
Самым сложным является наш вариант - ключ -Fc. здесь результаты будут существенно зависеть от двух факторов: размера файловой системы и дисковой активнгости в момент форматирования. Как крайние варианты: при файловой системе размером = объему оперативной памяти и при полном отсутствии обращений к диску файл может быть прочитан. несмотря на то, что информация из кэша блоков была уже удалена во время работы badblocks, информация в dcache сохранилась и файл может быть прочитан поскольку известны номера физических блоков на диске. К сожалению, ситуация на файловой системе большего размера или при наличии дисковой активности меняется на прямо противоположную. На моем компьютере попытка форматировать с ключом -с файловую систему с которой в данный момент я копирую файлы приводит к зависанию операционной системы. Без высокой дисковой активности система выживает, но все файлы оказываются недоступны.
Как осуществляет доступ команда dd, я, к своему стыду, не знаю и не могу гарантировать, что она использует те же системные вызовы, что и badblocks. Хотя, с 95% вероятностью, думаю, что это так. Кроме того, наверняка результаты подобных тестов могут различаться у разных людей в зависимости от множества факторов: старой (до форматирования) файловой системы, версии ядря, контроллера IDE и т.д.
К сожалению, простые и однозначные ответы ("запуск программы из кеша в ОЗУ вполне возможен. Более того: неизбежен") существуют только в убогом воображении отдельных недоучек. Которые не могут и не хотят ни посмотреть исходники, ни проверить свои "теории" экспериментом.

Резюме: запустить mke2fs повторно будет НЕЛЬЗЯ.

> Очень давно. Раз ты так крут, запусти тот же "top" и полюбуйся. Около 90% оперативной памяти окажется занято. Даже если все программы в общей сложности и 10% памяти не составят.

И что из этого следует? А метаданные не кэшируются, да? Давай ты будешь пиздеть более по существу и покажешь уже нам скриптик, где файл читается в кэш, удаляется, а потом исполняется?

>Уважаемый sS! Отвечаю Вам [skip]. Память подводит.
Ну не настолько же ;)
>Существует два
>вида дискового кэша: кэш элементов директорий (отсюда dcache.c) и >кэш физических блоков, читаемых с блочного устройства (файл buffer.c >в той же директории). Именно блочный кэш-то и перезапишет весь >остальной.

Xmm ... Вы наверное правы - перепишет при sync-е
но не так как Вы описали ...

int fsync_dev(kdev_t dev)
{
sync_buffers(dev, 0);
^^^^^^^^^^^^^^^^^^^^^^
не здесь

lock_kernel();
sync_inodes(dev);
^^^^^^^^^^^^^^^^^^^^^
а вот тут

DQUOT_SYNC_DEV(dev);
sync_supers(dev, 1);
unlock_kernel();

return sync_buffers(dev, 1);
}

> mke2fs -F

R00T, Вы хоть второй раз с незнанием Linux файловых систем не позорились бы принародно. :-(((

R00T должен научиться брать пример с умных людей. Например, с sS. Если он с чем-то не согласен, он находит кусок кода и выкладывает его в доказательство(правильное оно или неправильное - это уже другой вопрос. Но каждый может его легко проверить).

>Резюме: запустить mke2fs повторно будет НЕЛЬЗЯ.

#!/bin/bash
declare -i num_run=0;
trap "umount /mnt;exit" SIGINT
dd if=/dev/zero of=test.img count=4k
mke2fs -F test.img
mount test.img -o loop -t auto /mnt
cp `which mke2fs` /mnt/mke2fs
dd if=/dev/zero of=test.img count=4k
rm test.img
while true
do
num_run=$num_run+1;
/mnt/mke2fs -F test.img
echo /mnt/mke2fs run $num_run times;
sleep 1
done

Объясняй почему ;)

>R00T должен научиться брать пример с умных людей. Например, с sS. >Если он с чем-то не согласен, он находит кусок кода и выкладывает >его в доказательство(правильное оно или неправильное - это уже >другой вопрос. Но каждый может его легко проверить).

Не я был неправ - sync не убивает кеш - так что все действительно
может работать из кешу - главный вопрос не в этом а как товарисчу
восстановить его разделы - вот это действительно ВОПРОС

Вообще, некоторые старые пользователи ведут себя очень корректно (sS, Die-Hard, Dselect) и признают, если они не правы. Уважают не тех, кто не ошибается (таких нет), а тех, кто признаёт свои ошибки. Настоящий профи всё время учится, в том числе и на своих ошибках.

Анонимусу, объяснившему про опции -F, -Fc & -Fcc большое спасибо!

R00T должен уметь запускать top! Он знает, как наебать ядро!

Вообще на будующее хинт любителям запускать малопонятные
команды да еще и из под рута - главная команда в *NIX
это man - вот и нужно было пройтись по содержимому зловредного
скрипта этой командой

@sS
Простите, я не располагаю в данный момент временем, чтобы разобраться в Вашем сценарии и запустить его, поэтому отвечу из теоретических соображений: сценарий успешно отработает неограниченное число раз. Причина проста и очевидна (это маленький фокус с Вашей стороны стороны, я даже представляю как Вы улыбались, когда это писали) - сначала Вы создаете и монтируете файл. При этом создается файловая система, которая привязана не к имени файла, а к номерам блоков на диске. Потом Вы с помощью dd повторно создаете файл того же размера и с тем же именем. Вроде бы все то же самое. Но ниоткуда не следует, что он будет располагаться точно в тех же физических блоках. dd видит, что файл с заданым именем существует, поэтому, что она делает? Правильно, удаляет его. И создает новый. Если бы размер был разный, мы бы это сразу заметили: dd if=/dev/zero of=test.img count=1 отнюдь не обнулит первый блок этого файла, как наивно полагали бы некоторые windows-администраторы. Поэтому все дальнейшие операции (включая неразрушающий mke2fs) будут выполняться уже на второй копии файла. Ergo исходная программа в безопасности и будет работать столько, сколько понадобится.

P.S. Сейчас конец рабочего дня, так что до понедельника. Дома у меня доступа в интернет, к сожалению, нет