Eugene Berdnikov <b...@protva.ru> wrote: > On Mon, Mar 04, 2019 at 04:19:58PM +0300, Andrey Jr. Melnikov wrote: > > Eugene Berdnikov <b...@protva.ru> wrote: > > > On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote: > ... > > > > > в принципе, залить файлы в хранилище много ума не нужно. > > > > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то > > > > экзотику и работать с ней как с локальным диском - бесценно. > > > > У меня reprepro свято уверен, что репозиторий на локальной машине. > > > > > А у меня, к сожалению, нет уверенности в том, что при моргании сети, > > > на которое fuse выбросит I/O error, твоя приблуда не сломает репозиторий. > > > Потому как автор её скорее всего просто не предполагал, что репозиторий > > > может быть удалённым, а дороги к нему будут перепаханы и минированы. > > Он всегда такой, т.к. любая софтина пишет в неведомые дали. Эт вы просто > > привыкли, что типа "жосткий диск" он "рядом".
> Не только я, всё человечество к этому привыкло. Все пишут софт под > эту парадигму, потому что диск в системнике и бэкап в соседнем это > для большинства задач нормально по надёжности и оптимально по деньгам. Что-то тут у вас, бгатенька, не сходится. Если при записи воонтаго файла диск радостно отрапортовал UNC и ошибка поднялась до write(...) = -EIO а софтина этого не заметила - так ну её в /dev/null ту софтину. Каким образом поможет от этого бакап - моя не понимайт. Его то на данный момент нету? Нету. Записываемый датасет - того, агась. Тут бы конечно можно было применить drbd/ceph/gluster и прочую синхронщину - но оно для "ынтерпрайза" с терабитными каналами и стойками серверов. rsync и всякие надстройки вокруг него - тоже не помошники. Особенно если файлы по 10+G, rsync медленно и верно превращается в тыкву пожирающую процессор (если считает crc кусочками), а если не читает - то тыква жрет интернет гигабайтами. > А написать работающий с файлами транзакционно выверенный софт это столь > муторно, что получается лишь у профессионалов, занимающихся базами данных > и кластерами. У остальных обычно не получается. Например, стоит положить > файловую 1С с 5-15 юзерами на нестабильный канал, как через 2-3 месяца она > разлетается вдрызг, а техподдержка 1С тихо сопит и советует перейти на > трёхзвенку, т.е. архитектуру с транзакционным слоем снизу. Там и диски > по отношению к слою приложения оказываются локальными, неудивительно, > что на том же канале трёхзвенка 1С стабильно работает. Эмм, а причем тут эта виндовая хрень, которая на офтопике работает через "дай денег, дай, еще дай, ещё-ещё-ещё"? У неё задача такая - рассыпаться от любого чиха.
