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

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

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

А даты последнего изменения разные?

Разные. ФС - ext4.

testing

Delayed allocation and potential data loss? Её уже пофиксили?

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

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

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

Скор набиваешь?

Около четырёх лет назад.

Симптомы похожи.

Кстати в lost+found их случайно нет?

Нет, ничего нет. и fsck ничего не показывает.

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

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

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

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

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

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

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

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

и это ужасно

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

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

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

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, но систему перегрузили.

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

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

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

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

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

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

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

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

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

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