rPman

Используя fallocate создать файл нужного размера, если файловая система не поддерживает sparse files (дырявые файлы, не занимающие место на диске) то эта операция мгновенна а файл будет заполнен мусором (данными, которые лежали в секторах).

К сожалению (а точнее к счастью, ибо безопасность важнее) все современные файловые системы поддерживают дыры (они будут возвращать нули), т.е. физически файл не будет занимать место, и вам нужно будет либо самим заполнить файл нулями либо использовать опцию fallocate - FALLOC_FL_ZERO_RANGE, это физически записывает данные на диск, так что операция тратит время.

p.s. файловые системы со сжатием или online deduplication (типа zfs) тем более не позволят вам управлять процессом создания, точнее это нужно будет делать утилитами файловой системы.

upd. забыл еще напомнить, на файловых системах Copy On Write (типа zfs/btrfs/...) предварительное размещение файла бессмысленно, даже вредно, так как любая запись будет проходить в новое место на диске.

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

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

Поднимите на базе php вебсервер (или даже вебсокет сервер или оба, react вполне себе технология, с плюшками от nodejs, асинхронщины и прочее) в том случае ваши данные будут всегда в оперативной памяти и контролируемы вами (т.е. вы можете управлять кешированием (управление блокировками) на уровне логики приложения, вплоть до полного хранения в оперативной памяти в переменных, а не базы данных как прослойки), само собой нет необходимости выставлять этот сервер в сеть, пусть проксирующим будет ваш основной вебсервер, контролирующий пользователей на уровне запросов и даже авторизации, а ваше react приложение - отвечать за логику.

Из недостатков подхода, полученный бонус к скорости заметно отдалит необходимость перехода к многопроцессорной реализации, так как по умолчанию это single thread приложение (но само собой никто не мешает вам запускать несколько бакенд но блокировками управлять так же придется с оглядкой на это), т.е. разрабатывая приложение об этом почему то многие стараются не задумываться сразу, типа зачем и так все круто, но потом будет больно.

В некоторых случаях скорость может подняться тысячекратно.

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

upd. исправил в ответе redis на react (глупо попутал термины)

Разработка веб приложения это:
* дизайн
* верстка (требуется специалист умеющий css/html)
* фронтэнд - клиентская сторона
* бакэнд - серверная сторона
(а еще тестирование и юзабилити дизайн)

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

Главное отличие 'все сам с нуля' от 'использовать готовый фреймворк/cms' - в варианте готовый фреймворк вы получите все готовое но основное время вы будете тратить не на свою задачу, а бороться с особенностями и глюками этого готового решения. Грубо говоря вы получите что то готовое, много, голова кружится как легко и быстро вы это сделаете, но потом будете тратить много много времени чтобы добавить маленькую фичу, не предусмотренную разработчиком. И главное, поддержка со временем. Мало какой фреймворк живет дольше трех лет, какой там, через год разработчик посчитает что он сделан на устаревшей технологии и решит все переделать, забросив прежнее решение. А отсутствие поддержки это проблемы в кубе в продакшене.

Но если вы делаете свое решение, то поддержкой этого решения так же придется заниматься вам самим. Думайте об этом, когда будете оценивать 'стоимость' решения.

Истина где то посередине.

Скрытый приватный ключ в специальном чипе на устройстве.

Пример такого устройства - sim-карта, или специальный чип в смартфонах iphone и некоторых android, содержит секретный ключ, вытащить который невозможно, имеет чип, позволяющий шифровать данные этим ключом (асимметричные алгоритмы шифрования). Сервер может проверить что данные зашифрованы верным ключом.

https://en.wikipedia.org/wiki/Hardware_security_module

https://developer.android.com/training/articles/ke... - если аппаратного хранилища нет, его предоставит операционная система, это не так надежно но все же стоимость взлома высокая
https://developer.apple.com/documentation/security...
https://social.technet.microsoft.com/wiki/contents...
и т.п.

Для windows стандарта не придумали, да и устройства по умолчанию не поставляются. Для intel можно конечно покопаться, инструменты проприетарные есть, используются для хранения ключей oem и т.п. но эти инструменты обычно используются производителем железа (ноутбука) и скорее всего уже залочены.

Для десктопных машин используется практика usb hasp ключа, или usb ключ представляющийся в системе как клавиатура и генерирующий time code (коды, привязанные ко времени, например как google authenticator), сами устройства дешевые, уникальные, можно найти специальные программируемые (секретный ключ можно записать один раз и отправить клиенту), стоят не дорого (дороже доставка).

https://en.wikipedia.org/wiki/YubiKey

Порылся в интернете по поводу контроллеров, обслуживающих sdxc и не обнаружил упоминаний о каких-либо лимитах, но лучше конечно спрашивать железячников.

Но теоретически возможен искусственный лимит, определенный в софтварной части устройства, которая собственно обрабатывает логику и поддерживает exfat... зачем это может понадобиться производителю - очень просто, разграничить категории устройств по сегментам low end/mid end/high end, потому что на практике им уже очень сложно чем то другим это делать. Например людям подходит устройство не шибко производительное но с хорошим и емким хранилищем, производителю не нравится что люди этой категории покупают дешевое а не дорогое устройство, устанавливаем лимит на размер и вуаля - люди вынуждены покупать дорогое устройство.

Если это linux устройство, подобный лимит, если он имеет место быть, с некоторой долей вероятности можно будет убрать перепрошивкой устройства, но тут должно совпасть столько условий, которые китайские/корейские производители уже давно не выполняют (лицензия GPL и выдача исходников).

Утилита, первый запуск выдаст ссылку подключения доступа к аккаунту
gdrive-windows-x64.exe list -m 1000

дальше выдаст список файлов и каталогов (1000 лимит вывода, увеличивайте если нехватает), сохраняете в текстовый файл и открываете экселем (таблица с колонками фиксированной позиции, с пробелами) или чем вам там удобнее, размер в human readble варианте, ну выкрутитесь как-нибудь (формулой в экселе например).
----------------
Альтернатива:
Плагин к total commander, загружаете, добавляете, подключаетесь, делаете поиск *, жмете 'на панель', выделяете все, смотрите внизу размер.

Если плагин встретит каталог с символом / в имени, будет глючить и выдавать бесконечную рекурсию