>> Я проморгал про удаление, и писал про то, что на CoW мы
>> получим лапшу по всему диску хоть с преаллокацией, хоть без оной.
> А на обычных не-CoW ФС с преаллокацией не будет "лапши"?Прикинь - нет, не будет. Файл аллоцируется по возможности линейно, и перезапись идёт без изменения местоположения данных.
> Вообще же, разработка грамотной преаллокация довольно трудоёмка для любых современных ФС
Фееричненько.
> ФС научились учитывать размещение групп одинаковых байтов (того, что должно заполнить
> выделяемое место) и оптимизируют это размещение на стадии дисковой подсистемы.
БГГГ. Прошу прощения, но у меня сейчас уши в трубочку завернутся от того, что вы тут пишете. КАКОЕ ОТНОШЕНИЕ группы одинаковых байтов имеют к преаллокации занимаемого файлом дискового пространства? Задача преаллокатора - выделить максимально линейные блоки для файла, а какие ГРУППЫ БАЙТОВ туда будут записаны - его не волнует. Равно как и диск xD
> преаллокатора в торрент-клиенте, например, приходиться балансировать между скоростью
> преаллокации (записи специально сформирвоанного потока байтов — фактически псевдорандомного мусора)
It's epic, bro xD
> грамотная преаллокация заключается в том, чтобы перед началом скачивания торрент-контента (допустим, 10ГБ MKV) нужно каким-то образом скинуть на диск поток байтового
> мусора
И снова эпичное непонимание принципов работы FS. Суть в том, что всё "скидывание потока байтового мусора" сводится к ftruncate(file_handle, file_size). Нормальная FS при этом ничего, кроме метаданных, указывающих, где будет лежать файл, на диск не запишет.
> Однако современные ФС не учитывают физическое расположение секторов на диске (оперируют
> только LBA адресацией).
Последовательное чтение секторов на любых современных типах диска быстрее произвольного. Тчк. Всё остальное - лирика.
