Это просто подтверждает мой тезис о том что bash вообще ничего не умеет делать кроме как запускать процессы и принимать простейшие решения по коду ошибки.
Vi Vola, предположительно - делаешь штук 10 попыток с таймаутом растущим по экспоненте. Потом выходишь из программы. Нет смысла долбить диск который откючен (unmounted) или на нем закончилось свободное место.
Vi Vola, ну у тебя внутри while - что? Наверное файловые операции read. Read устанавливает код ошибки в errno. Проверяешь его. Что там... если он равен EBADF то файловый дескриптор сдох. И переоткрываешь его через open еще раз. Вообще об чем вопрос. Ты хочешь написать отказоустойчивое приложение которое 100 лет uptime простоит? Да железо столько не живет. Ты подержи своё приложение хотя-бы месяц работающим и понаблюдай за ошибками. И потом будешь знать куда соломки подстелить.
Добавлю просто еще 1 поинт против использования "С++". Это мощный язык но его шаблонный процессор часто приводит к неконтролируемому росту бинарника. Грубо говоря если сегодня взять сет утилит Линукса написанных на "C" и просто переписать их на "C++" с использованием ВСЕХ правил и ПРАКТИК современного С++ (в т.ч. Qt/Boost/STL и с использованием процессора шаблонов там где есть возможность) то полученный объем дистрибутива будет раза в 2 раза превышать дистрибутив Linux. Понравится ли пользователям тот факт что дистр вместо 1 DVD стал в дава раза толще и перформанс и использование кеша просело в 2 раза? Сомневаюсь. Вспомните сколько ругали Windows за тяжесть и увесистость? Гнев пользователей обрушится на новый С++ный Линукс также. Также тяжелее в 2 раза станут репозитарии бинарников. Вот такая плата за эксперимент.
По данному факту резкого распухания дистрибутива я готов спорить на коньяк хотя и слабо себе представляю кто может или кто в состоянии реализовать этот план хотя-бы на 5% чтобы получить выборку данных.
Я-бы взял ширину FULL_HD монитора. А высота - была-бы вариативной в зависимости от размера файла. Тебе-то зачем красивые пропорции? Тебе-ж не в фотошопе это смотреть. А для транспорта или контрабанды информации :)
Я не знаю какой engine ты используешь. Но для Oracle например для стандартных HEAP-organized tables, дисковое пространство в блоке не выделяется для пустых полей. Оно схлопывается. Поэтому экономия места тебя не должна беспокоить. Ну почитай документацию InnoDb/MyISAM что там с пустым местом.
Я имел дело с подобными связями 1:1 крупной системе для телефонного биллинга и общее впечатление было от нее - ужасное. Лучше такие связи не использовать. Так тебе проще писать запросы. Или создавай приходы столько сколько надо таблиц а левую часть их соедини в приход.
Попробуй запустить на обоих конфигурациях сборку с опцией -debug. И без параллелизма. Будет длинная постыня операций. Далее для двух конфигураций надо сравнить время. Я думаю в логе будет очевидно что какая-то одна операция долго исполнялась.
Так я не про проект говорю а про конфигурацию gradle на конкретной ОС. Посмотрите gradle.properties в инсталляции в GRADLE_HOME и в каталоге проекта. Возможно были различия.
Были ли равные условия? У Gradle есть .config где определяется максимальное число рабочих процессов --max-workers. Я думаю что они определяют скорость сборки много-модульного проекта. И еще gradle очень хитрый и при любой возможности пытается не компилировать когда есть возможность. Например запуск модульного теста может не вызвать полный цикл компиллятора. Тоесть это возможно не был вопрос Windows-vs-Linux а скорее один конфиг против другого.
Ramdrive - дорогое удовольсвие. Обычно память и так используется рационально. А если вы что-то под себя резервируете то другие приложения автоматически этого не получаю. Ramdrive - это конечно вариант. Но - кратковременный и управляемый вручную. После сборки вам надо не забыть его погасить.
Проводить аналогии на основании хитрости или на основании того что что-то там совместимо со Spark - это вообще большая натяжка. Почти 100% этих систем совместимы с jdbc как с основным драйвером взаимодействия с Java но родственность с JDBC их не делает более близкими по назначению.
