Невозможно распаковать очень большие файлы из / в корзины Google при монтировании с помощью gcsfuse

В Google Cloud у меня есть Linux Compute Engine и ведро. Я установил ведро в качестве накопителя на CE с помощью gcsfuse - в соответствии с рекомендациями Google - и время от времени у меня был большой архив 7zip (десятки ГБ), загруженный в корзину. Когда я вхожу в терминал CE, захожу в смонтированную папку корзины и пытаюсь разархивировать файл (в том же месте) с помощью команды: 7z x myarchive.7z он распакует файл до 100% (что займет пару минут) и при конец он потерпит неудачу с:

ERROR: E_FAIL

Archives with Errors: 1

После этого, если я смотрю на содержимое корзины, имя распакованного файла присутствует, однако его размер 0 КБ.

Я понимаю, что E_FAIL обычно ассоциируется с нехваткой места, но в корзине Google должно быть неограниченное пространство (с ограничениями на размер одного файла). Например, команда df -h говорит, что в смонтированном сегменте должно быть 1 петабайт доступного хранилища.

Кто-нибудь там с подобной настройкой / проблемой?


google-cloud-platform google-cloud-storage gcsfuse 7zip
person Vee6    schedule 15.04.2019    source источник
comment
Вы пробовали переместить файл на диск с экземпляром GCE и разархивировать его там? (просто чтобы проверить, связана ли проблема с креплением ковша). Кроме того, какова емкость диска виртуальной машины GCE по умолчанию? Возможно, при распаковке создаются временные файлы, слишком большие для этого диска виртуальной машины.   -  person norbjd    schedule 15.04.2019
comment
@norbjd В настоящее время я пересылаю файл на удаленный компьютер, где могу его распаковать. Диск виртуальной машины довольно низкий, около 10 ГБ, разархивирование идет на 100%, поэтому я предполагаю, что весь процесс дошел до конца где-то в некоторой памяти. Я выполняю эту команду из места в смонтированном ведре, и, делая это, я полагаю, что любое зарезервированное пространство также происходит там. Изменить: есть также тот факт, что в будущем будут архивы размером в несколько ТБ, и весь процесс должен держаться вместе.   -  person Vee6    schedule 15.04.2019
comment
Я не уверен, что запуск команды из смонтированного каталога гарантирует, что все файлы, созданные процессом распаковки, будут расположены в этом конкретном каталоге (например, временные файлы). Более того, файловая система смонтированного каталога не является классической файловой системой, поэтому на нее накладываются некоторые ограничения (например, в GCS нет случайной записи). Вот почему в процессе распаковки может потребоваться использование локального хранилища для выполнения некоторых задач.   -  person norbjd    schedule 15.04.2019
comment
Из документов (cloud.google.com/storage/docs/gcs-fuse# примечания) указывается, что: Случайная запись выполняется путем чтения всего большого двоичного объекта, его локального редактирования и записи всего измененного большого двоичного объекта обратно в облачное хранилище. Небольшие записи в большие файлы работают должным образом, но являются медленными и дорогостоящими.. Часть редактирование его локально может быть причиной вашей проблемы. Не могли бы вы попробовать подключить диск большей емкости (достаточной для хранения всех файлов в вашем архиве) и повторно запустить процесс распаковки?   -  person norbjd    schedule 15.04.2019
comment
Я изменил размер основного диска, чтобы освободить достаточно места, и, похоже, в конце концов это сработало. После того, как разархивирование было на 100%, мне потребовалось еще несколько минут, чтобы переместить файл из временной папки на жестком диске в корзину. Если вы опубликуете свое решение в качестве ответа, я буду поддерживать его.   -  person Vee6    schedule 16.04.2019

Ответы (1)


arrow_upward
2
arrow_downward

Как предлагается в комментариях, процесс распаковки может потребовать некоторых определенных операций в локальной файловой системе, даже если вы вводите команду из смонтированного каталога.

Действительно, поскольку файловая система, смонтированная с помощью GCS-fuse, не является классической файловой системой, некоторые операции могут потребовать переноса на локальный диск (это случай случайной записи, например, см. документацию):

Случайная запись выполняется путем чтения всего большого двоичного объекта, его локального редактирования и записи всего измененного большого двоичного объекта обратно в облачное хранилище. Небольшие операции записи в большие файлы работают должным образом, но являются медленными и дорогостоящими.

Чтобы гарантировать, что в процессе распаковки будет достаточно доступного размера для работы, и если предположить, что временные файлы, вероятно, создаются во время процесса, вам следует увеличить емкость вашего локального диска.

person norbjd    schedule 16.04.2019