Re: write-back cache в дисках и целостность данных

abrek

Не секрет, что часто для обеспечения целостности данных программа должна иметь возможность убедиться, что записанные данные достигли поверхности диска (или попали в иное энергонезависимое запоминающее устройство). Например, это относится к журналирующим файловым системам и базам данных.
Чуть менее распространено знание, что во многих современных дисках используется кеш, который позволяет аппаратуре переупорядочивать операции записи, добиваясь оптимальной производительности. В случае IDE-дисков включение write-back-кеширования в большинстве случаев приводит к невозможности гарантировать завершение операции записи. Я использовал для проверки вот эту программу:


#include <stdlib.h>

#include <stdio.h>

#include <unistd.h>

#include <sys/time.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#define BUFSZ 256

#define SECONDS 60

char buf[BUFSZ];

unsigned long *p = (unsigned long *) &(buf[0]);

int main(void)

{

        int fd;

        ssize_t ww;

        struct timeval tv1, tv2;

        *p = 0;

        fd = open("synctest", O_RDWR | O_CREAT, 0666);

        if (fd < 0) return 1;

        ww = write(fd, buf, BUFSZ);

        if (ww != BUFSZ) return 1;

        if (fsync(fd return 1;

        gettimeofday(&tv1, NULL);

        tv1.tv_sec += SECONDS;

        printf("Started\n");

        do {

                (*p)++;

                lseek(fd, 0, SEEK_SET);

                ww = write(fd, buf, BUFSZ);

                if (ww != BUFSZ) return 1;

                fdatasync(fd);

                gettimeofday(&tv2, NULL);

        } while (timercmp(&tv2, &tv1, < ;

        printf ("Finished: %lu iter, %lu RPM\n", *p, (*p * 60 / SECONDS;

        return 0;

}
s/fdatasync/fsync/ для систем, не имеющих функции fdatasync
Если f(data)sync реализуется честно, то каждое выполнение цикла требует не менее одного оборота диска, и количество RPM, которое сообщает программа, не превосходит реальной скорости вращения. Если же программа выдаёт нереально большое значение - значит, где-то обман.
Тестирование на IDE дисках под Linux подтвердило, что честность достигается только после выключения write cache (hdparm -W0)
(К сожалению, выключение приводит к охрененной потери производительности, цитату из tuning(7) от FreeBSD здесь уже неоднократно приводили).
На SCSI всё было нормально.
Однако сегодня попробовал запустить на FreeBSD со сказей (это shire) и увидел такое же нереально большое значение, в противоположность заявлению из tuning(7).
Где же правда?

Dasar

Ты серьезно считаешь, что тебе в этом форуме кто-то квалифицированно ответит на твой вопрос?

abrek

Вопрос риторический
На самом деле я надеюсь, что кто-нибудь проведёт аналогичный эксперимент с другими ОС/железом.
Вот например, на Sun Ultra 10 стоит вроде бы обычный IDE от Seagate. Так там этот кеш по умолчанию выключен. Субъективно - дисковая подсистема в несколько раз тормознее, чем похожий Seagate в PC (тоже с выключенным кешом). Возможно, этот эффект как-то связан со слухами, что IDE-диски от Seagate в любом случае включают кеш, если считают нагрузку достаточно большой (чтоб результаты бенчмарков лучше выглядели, а Sun могли попросить эту "фичу" отключить - но это уже дикие спекуляции).

Chupa

> На самом деле я надеюсь, что кто-нибудь проведёт аналогичный эксперимент с другими ОС/железом.
Linux 2.4.21-pre4-ac7
Software RAID1
2*(IBM IC35L030AVER07-0, 7200 RPM)
Write cache:
off 6892 RPM
on 175073 RPM
Теория полностью согласуется с практикой.

Chupa

> На SCSI всё было нормально.
> Однако сегодня попробовал запустить на FreeBSD со сказей (это shire) и увидел такое же
> нереально большое значение, в противоположность заявлению из tuning(7).
> Где же правда?
Просмотрел tuning(7) на shire. Про scsi write caching я там ничего не нашёл.
У scsi дисков вообще write caching настраивается? Или заранее предполагается его отсутствие?

abrek

> Про scsi write caching я там ничего не нашёл.
Там написано, юзайте SCSI, и всё у вас будет мягкое и шелковистое
> У scsi дисков вообще write caching настраивается? Или заранее предполагается его отсутствие?
Вроде бы настраивается, но скорее у контроллеров, чем у дисков. Дорогие это игрушки, я с ними почти не сталкивался.

sergey_m

> Чуть менее распространено знание, что во многих современных дисках
> используется кеш, который позволяет аппаратуре переупорядочивать
> операции записи, добиваясь оптимальной производительности.
Это нe write-back. Это Tagged Queueing. Он работает на всех современных SCSI дисках, а также на последних IDE от IBM.
write-back на SCSI дисках конфигурится в BIOS контроллера, и по умолчанию отключен, тк в условиях возможной потери питания
является опасным. Кстати говоря на shire он отключен. Идея write-back
более проста чем TQ - контроллер просто кэширует данные, которые следует записать на диск в своей памяти. (последнее - моё imho, могу ошибаться)

abrek

> Кстати говоря на shire он отключен.
Маза эксперимент показывает, что это не совсем так, о чём собственно и речь.

sergey_m

> > Кстати говоря на shire он отключен.
> Маза эксперимент показывает, что это не совсем так, о чём собственно
> и речь.
Аппаратный отключен наглухо. Результат эксперимента объясняется тем, что тест был запущен на файловой системе с softupdates. sync(2) на ней возвращается раньше, чем производится реальная запись на диск. Есть подозрение, что fsync(2) делает так же. Доказать это теоретически тяжело ввиду сложности кода. Если есть энтузиазм, то смотри softdep_fsync в файле ffs_softdep.c.

abrek

> sync(2) на ней возвращается раньше, чем производится реальная запись на диск. Есть подозрение, что fsync(2) делает так же.
vmstat показывает нехилый i/o, это не согласуется с твоей версией
проверьте ещё кто-нибудь, а то я не уверен, что правильно интерпретирую показания vmstat

bobking

Обожаю этот форум!
Нижеследующие высказывания касаются FreeBSD-4.7.
> на файловой системе с softupdates. sync(2) на ней возвращается раньше, чем производится реальная запись на диск.
Ну кто, кто, тебя всё время так жестоко обманывает?!
> Есть подозрение, что fsync(2) делает так же.
Дебильное подозрение.
Да, а в гугле ты смотрел про fsync и softupdates?
http://www.cnri.dit.ie/Downloads/fsopt.pdf

bobking

> касаются FreeBSD-4.7.
Впрочем, не только.

sergey_m

> > на файловой системе с softupdates. sync(2) на ней возвращается
> > раньше, чем производится реальная запись на диск.
> Ну кто, кто, тебя всё время так жестоко обманывает?!
sync(2):
BUGS
Sync may return before the buffers are completely flushed.

bobking

> > на файловой системе с softupdates. sync(2) на ней возвращается
> > раньше, чем производится реальная запись на диск.
> Ну кто, кто, тебя всё время так жестоко обманывает?!
sync(2):
BUGS
Sync may return before the buffers are completely flushed.
И каким боком тут softupdates?
Ты правда код смотрел? Ну глянь ещё раз, я очень тебя прошу.

sergey_m

Позже гляну, сейчас лень. А ты попробуй сделать так:
1) на fs с softupdates:
> rm BIG.FILE
> df
(смотрим, что место не освободилось)
> sync
> df
(смотрим, что место не освободилось)
(ждем некоторое время)
> df
видим что место освободилось
2) тоже самое на fs без softupdates.
После sync результат виден сразу же.
Команда sync, только и делает что вызывает sync(2).

TYU_2008

stat:~> uname -rsi
SunOS 5.8 i86pc
stat:~> ./dt
Started
Finished: 4943 iter, 4943 RPM
stat:~>

TYU_2008

s420r $ ./dt
Started
Finished: 3375 iter, 3375 RPM
s420r $ uname -rsi
SunOS 5.7 SUNW,Ultra-80
s420r $

bobking

Ты в инете участвуешь в форумах или рассылках каких? Может дашь URL, я хочу это видеть.
По поводу sync и soft updates:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ffs/ffs_softdep.c (смотри ревизии 1.94, 1.105).
И почитай сочинение МакКьюзика. Он хоть и пидар, но soft updates рюхает нипадецки.

TYU_2008

http://groups.google.com/groups?ie=UTF-8&oe=UTF-8&as_ugroup=fido7.ru.unix.*&as_uauthors=Gleb%20Smirnoff&lr=&hl=ru

sergey_m

Какой еще URL? Если тебе лень повторить, то вот:
morannon:~:|>mount | grep /home
/dev/da0s1f on /home (ufs, local, nodev, nosuid, with quotas, soft-updates)
morannon:~:|>df /home
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/da0s1f 9836244 8009638 1039708 89% /home
morannon:~:|>rm Short\ Circuit\ \(1986\).ShareReactor.avi
morannon:~:|>df /home
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/da0s1f 9836244 8009638 1039708 89% /home
morannon:~:|>sync
morannon:~:|>df /home
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/da0s1f 9836244 8009638 1039708 89% /home
morannon:~:|>
(минута прошла)
morannon:~:|>df /home
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/da0s1f 9836244 7335926 1713420 81% /home

sergey_m

И что?
http://groups.google.com.ru/groups?hl=ru&ie=UTF-8&oe=UTF-8&q=ksorokin%40mccme.ru&lr=&sa=N&tab=wg

bobking

Тупишь?
Ну прочитай ты commit messages по ссылке выше, там же чётко объяснена причина такого поведения.

sergey_m

1.94 описывает тот же глюк, что я продемонстрировал, только наоборот. df не замечает того, что место уже закончилось. 1.94 еще не MFC.
1.105 радует, но он еще не MFC. У меня этот глюк часто возникает.
Только я не понимаю какое это отношение имеет к возвращению из sync(2) для FreeBSD 4.7? Обе указанных тобой ревизии относятся к CURRENT. К обработке sync(2) для softupdates fs они тоже не имеют отношения.

abrek

Отцы, вы отошли от темы
Объясните лучше причину странного поведения вышеприведённого теста на FreeBSD

bobking

> Только я не понимаю какое это отношение имеет к возвращению из sync(2) для FreeBSD 4.7?
> [...]
> К обработке sync(2) для softupdates fs они тоже не имеют отношения.
И я не понимаю. Маза , что именно ты начал приклеивать проблему с df (размер свободного пространства) на файловой системе с softupdates к возвращению из sync.

bobking

> Объясните лучше причину странного поведения вышеприведённого теста на FreeBSD
Ты запускал свою программу на linux+scsi? Какое там поведение при отключенном кэше записи?
Если странное, то, маза, причина именно в TCQ.
Кстати, разве в линуксе есть поддержка TCQ для IDE винтов?
Да, патчи для этого существуют, но используются ли они реально в твоём дистрибутиве?

abrek

> Ты запускал свою программу на linux+scsi?
Да
> Какое там поведение при отключенном кэше записи?
Не знаю, как был настроен кеш, но скорость вращения дисков измерялась очень точно
> Кстати, разве в линуксе есть поддержка TCQ для IDE винтов?
Причём здесь это?

bobking

>> Кстати, разве в линуксе есть поддержка TCQ для IDE винтов?
> Причём здесь это?
Просто есть предположение, что странное поведение объясняется SCSI TCQ + технология soft updates (в силу особенностей последней).
На дятле с включенным hw.ata.tags оно, правда, не подтвердилось.
Маза Глебу стоит попробовать тест на SCSI на файловой системе без soft updates, но подмонтированной с флагом async.

sergey_m

> Маза напомнить, что именно ты начал приклеивать
> проблему с df (размер свободного пространства) на
> файловой системе с softupdates к возвращению из sync.
Я показал что sync действительно раньше возвращается, чем происходит запись на диск. df послужил иллюстрацией.

sergey_m

Винт IBM DPSS (7200 RPM, TQ)
> 3649 iter, 3649 RPM
softdep > 3646 iter, 3646 RPM
async > 7299 iter, 7299 RPM
Seagate Barracuda (7200 RPM, TQ)
> 65213 iter, 65213 RPM
softdep > 64403 iter, 64403 RPM
async > 161613 iter, 161613 RPM

abrek

> Seagate Barracuda (7200 RPM, TQ)
SCSI?

sergey_m

Оба.

abrek

Так что же, у Сигейта и в сказёвых дисках эта наёбка?

bobking

> Я показал что sync действительно раньше возвращается, чем происходит запись на диск.
Твой пример показывает лишь то, что df на ФС с soft updates врёт. Из него _не_ следует, что злобный sync забивает на какую-то часть данных.
Блин, ну если ломает смотреть исходники, то почитай ты МакКьюзика.

sergey_m

Поcле sync df врать не должен. Но он это делает. Потому что sync возвращается раньше, чем происходит реальная запись. И об этом написано в man. А df я вообще привел как частный случай, чего ты к нему прицепился?

sergey_m

Я не знаю как объяснить полученные результаты. Но, то что softupdates здесь не причем очевидно.

abrek

> А df я вообще привел как частный случай,
А другие примеры есть? Мои эксперименты с доступными машинами под FreeBSD не смогли обнаружить вообще какой-либо эффект от sync(8 но может быть я из-за отсутствия знаний об особенностях тамошнего VM просто не умею генерировать dirty pages в нужном количестве?

abrek

> Я не знаю как объяснить полученные результаты.
Больше всё-таки похоже на особенности аппаратуры. В машинах со сказёй и линуксом, на которых я тестировал, везде сигейты были, моделей не помню.
Может быть, где-нибудь ещё есть флажок про кеширование, который надо сбросить?

bobking

> BUGS
> Sync may return before the buffers are completely flushed.
Кстати, пресловутая строчка существует в мануале аж с 1994 года.
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/sys/sync.2?rev=1.1&content-type=text/x-cvsweb-markup

bobking

А контроллеры там какие?

sergey_m

Оба винта висят на AHA2940U2W и работают соответсвенно в режиме U2W.

sergey_m

Убедил
softupdates не причем.

abrek

Плохо, что не последовало реакции от тех, кто пользуется Windows.
Особенно учитывая это:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;281672
http://support.microsoft.com/default.aspx?scid=kb;en-us;332023

sergei1993

Ну если ты настаиваешь
То вот тебе замер моего единственного винта
IDE WD800JB
Write Cache Enabled: 117592 RPM
Write Cache Disabled: 6558 RPM
ЗЫ. Только не пойму, какой он может представлять интерес
ЗЗЫ. Поскольку я АЭС не рулю, то кэш отрубать не собираюсь.

sergei1993

ЗЗЫ ОС win2k pro sp3

abrek

> Аппаратный отключен наглухо.
В BIOS'е таки было включено, так что этот конкретный случай объяснён

Usmanova72

НУ сто тут эксперименты ставить. Это давно известный факт. На всех серваках отключают кеш для сохранности данных.

abrek

Не надо говорить за всех.
Известно не всем, и отключают не все, и у некоторых есть причины не отключать.
А на IDE это вообще страшная потеря производительности.
Правда сейчас для Linux активно разрабатывается write-barrier support для IDE, может скоро смогу потестировать.
Оставить комментарий
Имя или ник:
Комментарий: