Re: Генерация pool-based репозиториев
Eugene Berdnikov <bd4@protva.ru> wrote:
> On Mon, Mar 04, 2019 at 04:19:58PM +0300, Andrey Jr. Melnikov wrote:
> > Eugene Berdnikov <bd4@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С стабильно работает.
Эмм, а причем тут эта виндовая хрень, которая на офтопике работает через
"дай денег, дай, еще дай, ещё-ещё-ещё"? У неё задача такая - рассыпаться от
любого чиха.
Reply to: