LINUX.ORG.RU
ФорумAdmin

Потеря данных в директории, смонтированной через -o bind

 ,


0

4

Дело такое. Есть в системе (debian testing) два диска - sda1 (SSD) и sdb1 (HDD). sdb1 смонтирован в /storage, sda1 - в /. Решил я переместить /var с sda1 на sdb1. Новую партицию делать было влом, поэтому решил следующим образом:

cp -rp /var /storage/var
mount -o bind /storage/var /var

Все работало отлично, но в один прекрасный момент все данные из в /storage/var пропали. Пропали тупо на ровном месте, когда на сервере никого не было. Файлы на месте, но у всех размер - 0 байт. В логи соответственно тоже не посмотришь, так как все они стерты. В баш-хистори ничего преступного не нарыл. Остальные файлы на sdb1 целые. fsck ошибок на sdb1 не показывает. Я совершенно не могу понять, в чем могла быть причина. Может кто-то сталкивался с подобными глюками?

★★★★★

Файлы на месте, но у всех размер - 0 байт

А даты последнего изменения разные? Какая файловая система?

ziemin ★★
()

Если мне не изменяет склероз, mount_bind никогда не выходил из стадии pre-alpha и использование его сильно не рекомендуется. Т.ч. ССЗБ, ничего не поделаешь.

beastie ★★★★★
()
Ответ на: комментарий от beastie

Не говорите ерунды. mount --bind прекрасно работал ещё даже в 2.4.

У ТСа всё таки похоже проблема с фс/железом. А потерялись именно эти файлы, т.к. были недавно скопированы.
Кстати в lost+found их случайно нет?

Nao ★★★★★
()
Ответ на: комментарий от provaton

Попробуй чем-нибудь вроде testdisk полазить. Только не ставь его на тот-же раздел. Лучше livecd какой найди.

ziemin ★★
()
Ответ на: комментарий от leave

это плохо? денег то тут не заработаешь.

а человек используя дистрибутив со статусом тестинг, жалуется на лор а не в багтрекер. Тоже ради скора это делает?

ukr_unix_user ★★★★
()
Ответ на: комментарий от ukr_unix_user

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

leave ★★★★★
()
Последнее исправление: leave (всего исправлений: 1)
Ответ на: комментарий от leave

что вам логика покоя не даёт? человеки не всегда логичны в своём поведении и поступках. ЛОР тому пример. толпа приходит что-то спрашивает, что-то отвечает. Толку мало. Так, потрындеть в основном, сюда приходят.

ukr_unix_user ★★★★
()

Покажите вывод команды stat на часть этих файлов.

Работало достаточно долго это сколько? logrotate ротировал логи в /storage/var? Перезагрузки системы были?

mky ★★★★★
()
Ответ на: комментарий от ukr_unix_user

человеки не всегда логичны в своём поведении и поступках.

и это ужасно

leave ★★★★★
()
Ответ на: комментарий от mky

вывод stat вот здесь - https://dl.dropbox.com/u/16829613/stats.txt

Работало примерно с 27 марта 14:00, заметили 29 марта около 6:00-7:00. Напарник запаниковал и сразу перезагрузился ничего не исследуя, но утверждает, что проблемы были до перезагрузки такие же. Больше перезагрузок не было. Дневная ротация скорей всего была.

provaton ★★★★★
() автор топика
Ответ на: комментарий от provaton

С временными метками файлов какая-то фигня. Вот допустим

cache/apt/archives/memcached_1.4.13-0.2_amd64.deb'
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 811h/2065d	Inode: 16124565    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-03-27 12:17:32.462218181 -0500
Modify: 2013-01-23 14:33:29.000000000 -0600
Change: 2013-03-28 14:29:35.602584104 -0500

2013-03-27 12:17:32 видимо время когда его копировали.

2013-01-23 14:33:29 похоже на время установки/обновления пакета.

А вот ″Change: 2013-03-28 14:29:35″ это похоже, когда файлы обнулились. Причём у разных файлов это время отличается в долях секунды. То есть как будто их последовательно обнуляли наподобие ″echo > memcached_1.4.13-0.2_amd64.deb″, но при этом почему то не изменилось время модификации (Modify).

Ещё странно, что нет ″messages″, ″syslog″ и других log-файлов, есть только ротированные варианты (″messages.1″, ″syslog.1″), или вы их убрали из вывода?

С подобными глюками не сталкивался, интерестно было бы посмотреть, что было в dmesg, но систему перегрузили.

mky ★★★★★
()
Ответ на: комментарий от mky

Ещё странно, что нет ″messages″, ″syslog″ и других log-файлов, есть только ротированные варианты (″messages.1″, ″syslog.1″), или вы их убрали из вывода?

Насколько я понимаю, messages и syslog в дебиане ротируются после перезагрузки. Поэтому, они после перезагрузки были уже не пустые и в вывод не попали (я делал find /storage/var.bak/ -size 0 -exec stat {} \;)

Сейчас попробовал еще раз перенести /var, только сейчас уже сделал не «на горячую», а прописал маунт в fstab и перезагрузился.

Единственное подозрение у меня, что это все произошло из-за того, что я сделал mount --bind на работающей системе, и не перезапускал никакие сервисы после этого. Это, конечно, была моя ошибка, но если в этом причина, то почему обнулились такие файлы как, например, listchanges.db, которые не держатся постоянно открытыми?

provaton ★★★★★
() автор топика
Ответ на: комментарий от ukr_unix_user

а человек используя дистрибутив со статусом тестинг, жалуется на лор а не в багтрекер.

Я не жалуюсь. Тестинг использую сознательно, так как сервер этот еще пока не продакшен. Пока дорастет до продакшена, тестинг как раз зарелизиться должен. В багтрекер глупо жаловаться так как для этого надо четко понимать в чем проблема, а тут пока такого понимания у меня нет.

provaton ★★★★★
() автор топика
Ответ на: комментарий от provaton

из-за того, что я сделал mount --bind на работающей системе, и не перезапускал никакие сервисы после этого

К таким последствиям это привести не должно было. Конечно, демонов надо было перезапустить, так как если у них были открыты файлы в /var/*, то после mount они бы работали с ранее открытыми файлами из /var/ на sda, а новые файлы создавали бы в /var/ на sdb. Какие-нибудь сложные структуры данных, размазанные на несколько файлов могли стать несогласованными, но логи и уж тем более cache/apt вобще никак не должны были быть затронуты.

Да, и если вы не перезапускали syslogd, то ведь он должен был продолжать писать логи в /var/log на sda.

mky ★★★★★
()
Ответ на: комментарий от ukr_unix_user

И что? Он все равно старее Ubuntu, Arch, Gentoo и прочего, в которых таких гадостей нет.

KendovNorok
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.