ᅠА
если есть свои серваки почему бы не использовать nextcloud + onlyoffice.
Своих серваков нету, почта в яндекс конект, задача вообще для одного отдела там человек 20 да и почта сейчас в конекте, все таки думаю что яндекс диск норм решение
Size: a a a
2019 August 30
SP
Привет. А ктонибуть знает тулзу которая может в многопоточное копирование больших файлов под linux?
Vs
ну просто диск шарить наверное да... если ничего секретного там нет...
Vs
а то яндекс тут пару лет назад косанул и выложил все файлы в общий доступ... ну вернее они стали выдаваться в поисковой выдаче...
SP
а то яндекс тут пару лет назад косанул и выложил все файлы в общий доступ... ну вернее они стали выдаваться в поисковой выдаче...
А ещё был билд Яндекс диска который форматировал системный диск при обновлении))
ДГ
Что я делаю не так? )
Есть squid )
Кофигурация тут:
Содержание
Хотя в запросе я вижу что тип данных
Есть squid )
Кофигурация тут:
/etc/squid/squid.confacl block_list_mime rep_mime_type -i "/etc/squid/block_list.mime"http_reply_access deny block_list_mimeСодержание
/etc/squid/block_list.mime:application/x-msdos-program
application/x-msi.msi блокирует, а .exe почему то нет )Хотя в запросе я вижу что тип данных
application/x-msdos-program при передачи .exe )На помни как писать синим цветом. чет <pre> не пашет
n
Привет. А ктонибуть знает тулзу которая может в многопоточное копирование больших файлов под linux?
(мы говорим о копировании внутри файловой системе?) Мне кажется, даже если есть какая-нибудь тулза, которая по-блочно копирует с А в Б, то даже если учесть такие факторы как:
-
- если тулза будет в N-cores (hyperthread включен) считывать по 2 Гига памяти больших файлов, то все равно будет ограничение в SATA шине.
Поэтому самым оптимальным решением является хардварный апргейд - https://www.amazon.com/External-Converter-Adapter-Enclosure-Support/dp/B07FY6FD4K/ref=asc_df_B07FY6FD4K
-
read сисколл в не зависимости от 32-bit, 64-bit системы, максимально считывает 2 Гигабайта- если тулза будет в N-cores (hyperthread включен) считывать по 2 Гига памяти больших файлов, то все равно будет ограничение в SATA шине.
Поэтому самым оптимальным решением является хардварный апргейд - https://www.amazon.com/External-Converter-Adapter-Enclosure-Support/dp/B07FY6FD4K/ref=asc_df_B07FY6FD4K
ДГ
read Вот так какДГ
писать
SP
(мы говорим о копировании внутри файловой системе?) Мне кажется, даже если есть какая-нибудь тулза, которая по-блочно копирует с А в Б, то даже если учесть такие факторы как:
-
- если тулза будет в N-cores (hyperthread включен) считывать по 2 Гига памяти больших файлов, то все равно будет ограничение в SATA шине.
Поэтому самым оптимальным решением является хардварный апргейд - https://www.amazon.com/External-Converter-Adapter-Enclosure-Support/dp/B07FY6FD4K/ref=asc_df_B07FY6FD4K
-
read сисколл в не зависимости от 32-bit, 64-bit системы, максимально считывает 2 Гигабайта- если тулза будет в N-cores (hyperthread включен) считывать по 2 Гига памяти больших файлов, то все равно будет ограничение в SATA шине.
Поэтому самым оптимальным решением является хардварный апргейд - https://www.amazon.com/External-Converter-Adapter-Enclosure-Support/dp/B07FY6FD4K/ref=asc_df_B07FY6FD4K
Нет по сети.
n
Нет по сети.
открыть 10+ TCP соединений, и отправлять
wget -ом, который сможет в случае чего продолжить с места последней закачки.. Параллелизация опять таки упрется в uplink bandwidthSP
открыть 10+ TCP соединений, и отправлять
wget -ом, который сможет в случае чего продолжить с места последней закачки.. Параллелизация опять таки упрется в uplink bandwidthКак то слишком замороченно
Vs
Как то слишком замороченно
тогда scp и не морочиться голову
SP
тогда scp и не морочиться голову
У scp проблема с копированием файлов от терабайта
n
У scp проблема с копированием файлов от терабайта
разбей на части
ddSP
Это все изврат. А потом собирать это файл склеивать.
Vs
filezilla ....
Vs
с удаленного сервера
Vs
она должна хавать такие файлы
Vs
ну клиент разумеется