11 марта 2014 г., 11:36 пользователь Alexander Yerenkow
<[email protected]> написал:
>
>
>
> 11 марта 2014 г., 11:27 пользователь Anton Sayetsky <[email protected]>
> написал:
>
>> 11 марта 2014 г., 10:25 пользователь Alexander Yerenkow
>> <[email protected]> написал:
>> >
>> >
>> >
>> >
>> >> Тут всё правильно - меньше 12к не получится с учётом ashift.
>> >> И если создать файл размером в 100к - то он у меня 100к и занимает.
>> >
>> > Занимает файл или его блок?
>> >
>> >> Так что теперь мне непонятно, почему при записи файла размером 484к я
>> >> получаю 4*128, а не 3*128+100
>> > Эмм, так вроде ж ты в начальных условиях указал что "имеем dataset c
>> > recordsize=128k", плюс у тебя выполняется условие что файл уже состоит
>> > из
>> > нескольких блоков, дальше он (судя по инфе что я читал) будет
>> > дополняться
>> > именно кусками в recordsize.
>> > Ну и плюс чексум считается именно по всему блоку, если мы не знаем что
>> > там
>> > было до нас, то надо туда писать весь блок, включая padding zeroes (или
>> > как
>> > оно у них там).
>> >
>> > Примерно то что ты спрашивал, или я не уловил суть?
>> Пишу файл 9.5к - занимает 12к.
>> Пишу файл 100к - занимает 100к.
>> Пишу файл 484к - занимает 512, а не 484к.
>> Я ж вроде указал вывод zdb. :) Я не понял, почему для файла размером
>> 484к последний блок - 128, а не 100к.
>
>
> Потому что это не первый блок, а N-ный ( N > 1), для этих файлов ZFS считает
> что это уже в некоторой степени large file, и пишет блоками по recordsize.
Ага, т.е. если для первого блока набралось recordsize, то все
последующие пойдут с этим размером и padding, если данных не хватает?
А из предыдущего получается, что если записать 2 раза по 64к с
задержкой >txg timeout, то из-за CoW получится не 2*64, а 1*128.
