Здравствуйте, halo, Вы писали:

H>/blobs/$HASHED_FILE
H>/files/$TYPE/$TENANT_ID/$HASHED_FILENAME

H>где:

H>* $HASHED_FILE -- имя файла, составляемое из хеша содержимого этого же файла в виде строки в base16;
H>* $HASHED_FILENAME -- символическая ссылка в виде хеша имени оригинального файла в base16, узывающая на блоб из директории /blobs.

H>Все три (на самом деле, нет: кроме второй) вышеуказанные проблемы в обозримом будущем покрываются таким подходом. Так, пока невозможный в этой системе /files/backgrounds/162/пустой-файл.bin мог бы быть представлен на файловой системе следующим образом (пускай хеш-функцией будет SHA-1):

H>/blobs/da/39a3ee5e6b4b0d3255bfef95601890afd80709 -- пустой файл
H>/files/backgrounds/162/05/562e534a175beadd7c5c5504af329b02e2ffbb -- символическая ссылка на /blobs/da/39a3ee...709

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

Если не планируется большой выигрыш от дедубликации файлов (оценить это можно уже сейчас), я бы убрал отдельное хранение блобов.
Если оно всё-же нужно, то стоит внести дополнительный слой — экземпляры файлов с хардлинками на исходник (примерно так делает dovecot):

/blobs/$HASHED_FILE-$TENANT_ID -> (hardlink to) -> /blobs/hashes/$HASHED_FILE
/files/$TYPE/$TENANT_ID/$HASHED_FILENAME -> (softlink to) -> /blobs/$HASHED_FILE-$TENANT_ID

Тогда алгоритм удаления будет таким: снести ссылку в каталоге пользователя, хардлинк по этой ссылке и если больше хардлинков не осталось, снести сам блоб.

Здравствуйте, halo, Вы писали:

H>/blobs/$HASHED_FILE
H>/files/$TYPE/$TENANT_ID/$HASHED_FILENAME

H>где:

H>* $HASHED_FILE -- имя файла, составляемое из хеша содержимого этого же файла в виде строки в base16;
H>* $HASHED_FILENAME -- символическая ссылка в виде хеша имени оригинального файла в base16, узывающая на блоб из директории /blobs.

H>Все три (на самом деле, нет: кроме второй) вышеуказанные проблемы в обозримом будущем покрываются таким подходом. Так, пока невозможный в этой системе /files/backgrounds/162/пустой-файл.bin мог бы быть представлен на файловой системе следующим образом (пускай хеш-функцией будет SHA-1):

H>/blobs/da/39a3ee5e6b4b0d3255bfef95601890afd80709 -- пустой файл
H>/files/backgrounds/162/05/562e534a175beadd7c5c5504af329b02e2ffbb -- символическая ссылка на /blobs/da/39a3ee...709

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

Если не планируется большой выигрыш от дедубликации файлов (оценить это можно уже сейчас), я бы убрал отдельное хранение блобов.
Если оно всё-же нужно, то стоит внести дополнительный слой — экземпляры файлов с хардлинками на исходник (примерно так делает dovecot):

/blobs/$HASHED_FILE-$TENANT_ID -> (hardlink to) -> /blobs/hashes/$HASHED_FILE
/files/$TYPE/$TENANT_ID/$HASHED_FILENAME -> (softlink to) -> /blobs/$HASHED_FILE-$TENANT_ID

Тогда алгоритм удаления будет таким: снести ссылку в каталоге пользователя, хардлинк по этой ссылке и если больше хардлинков не осталось, снести сам блоб (и как-то избежать racing condition).