Комментарии 45
То есть файловая система у них это по сути не-SQL БД с версионностью?
Интрересно, почему они выбрали использовать софтверный (я правильно понял) RAID, неужели хватает производительности?
Интрересно, почему они выбрали использовать софтверный (я правильно понял) RAID, неужели хватает производительности?
1. Ну в общем да. Первоначально в качстве «языка запросов» использовался, как ни парадоксально звучит — NFS. Пото, после того, как они добавли CIFS и FC/iSCSI все стало сложнее, но идея та же. Да, база с версионностью как хранилище записей о файлах.
Впрочем, есть мнение, что называть WAFL файловой системой в чистом виде, как мы это понятие трактуем сейчас, нельзя. Об этом я тоже попозже напишу наверное, как соберу мысли. Но по традиции принято называть ее FS.
2. Ну во первых помните, что WAFL появилась году в 93-м, значит начали ее разрабатывать этак в 92, не позднее. А сам термин RAID как таковой появился впервые в научной статье, опубликованной в 87-м году, так что, подозреваю, выбор «аппаратных контроллеров» достаточной мощности на тот момент был невелик :)
Во вторых, страхи вокруг «софтверности» RAID «несколько преувеличены». Вон большие enterprise сервера SUN юзают, и ничего.
К тому же часто у людей есть несколько превратное представление о разнице «аппаратного» и «программного» RAID. В аппаратном же не специальные наногномики байтики перетаскивают. Там точно также процессор, память, и программа на этом процессоре. То есть это есть самый что ни на есть «программный» RAID, просто на отдельном процессоре.
Процессор системы хранения не занимается по сути ничем другим, кроме задач хранения, поэтому хорошо отлаженный «софтверный» RAID на такой системе ничем не хуже (на практике — лучше, потому что процессор обычно быстрее), чем отдельная плата с отдельным процессором.
Просто воспринимайте всю систему в целом как такой большой RAID-контроллер в ящике. :)
В третьих изначально системы планировались в массовый, недорогой рынок, а цены на компьютерное железо тогда были совсем не те что сейчас. И попытка использовать «аппаратный» RAID стороннего производителя резко бы увеличило стоимость решения и убило бы проект.
В четвертых (вы не устали?;), и это, наверное, само важное, процитирую одного нетапповского инженера: «все файловые системы работают поверх RAID. Но только наш WAFL и его WAFL RAID знают друг о друге так много, что могут использовать взаимные достоинства и компенсировать недостатки друг друга при работе».
Впрочем, есть мнение, что называть WAFL файловой системой в чистом виде, как мы это понятие трактуем сейчас, нельзя. Об этом я тоже попозже напишу наверное, как соберу мысли. Но по традиции принято называть ее FS.
2. Ну во первых помните, что WAFL появилась году в 93-м, значит начали ее разрабатывать этак в 92, не позднее. А сам термин RAID как таковой появился впервые в научной статье, опубликованной в 87-м году, так что, подозреваю, выбор «аппаратных контроллеров» достаточной мощности на тот момент был невелик :)
Во вторых, страхи вокруг «софтверности» RAID «несколько преувеличены». Вон большие enterprise сервера SUN юзают, и ничего.
К тому же часто у людей есть несколько превратное представление о разнице «аппаратного» и «программного» RAID. В аппаратном же не специальные наногномики байтики перетаскивают. Там точно также процессор, память, и программа на этом процессоре. То есть это есть самый что ни на есть «программный» RAID, просто на отдельном процессоре.
Процессор системы хранения не занимается по сути ничем другим, кроме задач хранения, поэтому хорошо отлаженный «софтверный» RAID на такой системе ничем не хуже (на практике — лучше, потому что процессор обычно быстрее), чем отдельная плата с отдельным процессором.
Просто воспринимайте всю систему в целом как такой большой RAID-контроллер в ящике. :)
В третьих изначально системы планировались в массовый, недорогой рынок, а цены на компьютерное железо тогда были совсем не те что сейчас. И попытка использовать «аппаратный» RAID стороннего производителя резко бы увеличило стоимость решения и убило бы проект.
В четвертых (вы не устали?;), и это, наверное, само важное, процитирую одного нетапповского инженера: «все файловые системы работают поверх RAID. Но только наш WAFL и его WAFL RAID знают друг о друге так много, что могут использовать взаимные достоинства и компенсировать недостатки друг друга при работе».
Только не надо забывать, что на процессор общего назначения аккумуляторную батарею не повесишь ;)
Другой вопрос что в данном (WAFL) случае, это «как бы» не страшно и не обязательно.
Другой вопрос что в данном (WAFL) случае, это «как бы» не страшно и не обязательно.
Особенно радует термин «недорогой рынок». Вот S300 был недорогой, но прикрыли же лавочку. :(
А файловая система замечательно сделана, единственный непонятный момент — как решается падение производительности записи со временем.
Например:
1) берем пишем файл на 99% емкости, и начинаем его усиленно менять
2) пишем много-много-много маленьких файлов (на 50% емкости) и начинаем их усиленно менять…
А файловая система замечательно сделана, единственный непонятный момент — как решается падение производительности записи со временем.
Например:
1) берем пишем файл на 99% емкости, и начинаем его усиленно менять
2) пишем много-много-много маленьких файлов (на 50% емкости) и начинаем их усиленно менять…
В самом начале это были действительно недорогие системы, особенно в свете того, что их конкурентами были сервера Sun и Auspex, за многие десятки и сотни тысяч долларов.
Но потом постепенно пошли большие задачи и большие системы, а зарабатывать на больших системах тривиально проще.
Ценовая война с «китайцами» еще никому не удалась, а погубила многих именитых, тот же 3Com, например. Где он тот триком, ау. ;(
«падение производительности записи со временем» решается правильной настройкой и правильным использованием системы.
Вот результаты
www.storageperformance.org/results/a00062_NetApp_FAS3040-48hr-sustain_executive-summary.pdf
Если, конечно, ваша задача не описывается анекдотом про суровых сибирских мужиков и новую японскую бензопилу ;)
Но потом постепенно пошли большие задачи и большие системы, а зарабатывать на больших системах тривиально проще.
Ценовая война с «китайцами» еще никому не удалась, а погубила многих именитых, тот же 3Com, например. Где он тот триком, ау. ;(
«падение производительности записи со временем» решается правильной настройкой и правильным использованием системы.
Вот результаты
www.storageperformance.org/results/a00062_NetApp_FAS3040-48hr-sustain_executive-summary.pdf
Если, конечно, ваша задача не описывается анекдотом про суровых сибирских мужиков и новую японскую бензопилу ;)
Да не забросает меня камнями track за комментарий.
Ваш вопрос весьма в точку, проблема падения производительности со временем есть(и от других факторов, например заполненность агрегаты и количество непрерывных свободных мест, также недаром сразу 10% съедается на т.н. WAFL резерв, одна из задач которого как раз обеспечить наличие места для поддержания скорости записи), однако до сих пор NetApp как-то обходит её пристальным вниманием (никакой официальной статистики, никаких best practice или специальных мануалов).
У конкурентов и злых языков эта одна из излюбленных тем для FUD — «а зачем NetApp поставляет вместе с системой хранения программу дефрагментации???».
На самом деле т.н. reallocate это часть операционной системы предназначенный как раз чтобы выправить ситуацию (если возникла) с неоптимальным расположением данных на WAFL.
Однако как уже сказал ниже track при правильно настроенной системе такая проблема решима («правильное использование» :) ). Может появится очень не скоро (зависит от многих факторов) или не появится вообще. Самый типовый случай — расширение агрегаты новыми дисками, т.е. в одной или нескольких райд группах появляются новые диски.
Ваш вопрос весьма в точку, проблема падения производительности со временем есть(и от других факторов, например заполненность агрегаты и количество непрерывных свободных мест, также недаром сразу 10% съедается на т.н. WAFL резерв, одна из задач которого как раз обеспечить наличие места для поддержания скорости записи), однако до сих пор NetApp как-то обходит её пристальным вниманием (никакой официальной статистики, никаких best practice или специальных мануалов).
У конкурентов и злых языков эта одна из излюбленных тем для FUD — «а зачем NetApp поставляет вместе с системой хранения программу дефрагментации???».
На самом деле т.н. reallocate это часть операционной системы предназначенный как раз чтобы выправить ситуацию (если возникла) с неоптимальным расположением данных на WAFL.
Однако как уже сказал ниже track при правильно настроенной системе такая проблема решима («правильное использование» :) ). Может появится очень не скоро (зависит от многих факторов) или не появится вообще. Самый типовый случай — расширение агрегаты новыми дисками, т.е. в одной или нескольких райд группах появляются новые диски.
Ситуация с фрагментацией насамом деле действительно непроста.
Вот, например, много лет считалось, что inode-овые (UNIX-ного типа, наследники FFS) файловые системы мало подвержены эффекту фрагментации в принципе. Тем не менее, спустя 20 лет их развития большинство новых FS имеют утилиты устранения фрагментации (пример — ext4, xfs). Значит фрагментация на UNIX действительно существует, вопреки ранее считавшемуся, и с ней надо бороться?
По видимому да.
Так что ответом на вопрос «почему поставляет» будет контрвопрос: «а почему вы не поставляете, на что надеетесь?»
С другой стороны, фрагментация данных мало влияет, если характер чтения фрагментированных данных — random.
А именно такой характер носит современный характер использования данных в многозадачных OS, в системах виртуальной серверной инфраструктуры, гипервизоров, OLTP-баз.
Случайное чтение случайно расположенных на диске блоков данных ничем не отличается с точки зрения seek overhead от случайного чтения последовательно расположенных данных. В обеих случаях чтение идет мелкими блоками и случайно.
Третий момент состоит в том, что, несмотря на то, что WAFL действительно _может_ писать данные «куда угодно», из этого совсем не слдует, что она _на самом деле_ пишет их «куда угодно».
Пример — использование так называемых «экстентов», то есть если система видит, что записываемые данные располагаются последовательно, то она постарается записать их в послдовательные цепочки блоков, что, конечно, снижает фрагментацию.
Я писал ранее про большую задачу, которую решала компания Weta Digital, и когда я связался с ее автором, среди прочего, я спросил и как он относится к проблеме фрагментации на NetApp (не скрою, я сам этой темой очень интересуюсь, чтобы сложить свое об этом представление).
Так вот человек сказал, что, несмотря на то, что их требования к производительности системы были чрезвычайно высоки, что они твикали буквально все, ради достижения нескольких процентов прироста (благо они использовали Linux в качестве OS узлов их гигантской рендерфермы), они _вообще_ не занимались проблемой фрагментации, сочтя ее незначительной во влиянии на производительность системы хранения в целом.
Безусловно можно придумать такое сочетание рабочих нагрузок и характера хранимых данных, и доступа к ним, когда это будет влиять. Но вопрос, насколько это реальная задача, не уподоблямся ли мы пресловутым сибирским мужикам, которые испытывали новую японскую бензопилу из анегдота. :)
Вот, например, много лет считалось, что inode-овые (UNIX-ного типа, наследники FFS) файловые системы мало подвержены эффекту фрагментации в принципе. Тем не менее, спустя 20 лет их развития большинство новых FS имеют утилиты устранения фрагментации (пример — ext4, xfs). Значит фрагментация на UNIX действительно существует, вопреки ранее считавшемуся, и с ней надо бороться?
По видимому да.
Так что ответом на вопрос «почему поставляет» будет контрвопрос: «а почему вы не поставляете, на что надеетесь?»
С другой стороны, фрагментация данных мало влияет, если характер чтения фрагментированных данных — random.
А именно такой характер носит современный характер использования данных в многозадачных OS, в системах виртуальной серверной инфраструктуры, гипервизоров, OLTP-баз.
Случайное чтение случайно расположенных на диске блоков данных ничем не отличается с точки зрения seek overhead от случайного чтения последовательно расположенных данных. В обеих случаях чтение идет мелкими блоками и случайно.
Третий момент состоит в том, что, несмотря на то, что WAFL действительно _может_ писать данные «куда угодно», из этого совсем не слдует, что она _на самом деле_ пишет их «куда угодно».
Пример — использование так называемых «экстентов», то есть если система видит, что записываемые данные располагаются последовательно, то она постарается записать их в послдовательные цепочки блоков, что, конечно, снижает фрагментацию.
Я писал ранее про большую задачу, которую решала компания Weta Digital, и когда я связался с ее автором, среди прочего, я спросил и как он относится к проблеме фрагментации на NetApp (не скрою, я сам этой темой очень интересуюсь, чтобы сложить свое об этом представление).
Так вот человек сказал, что, несмотря на то, что их требования к производительности системы были чрезвычайно высоки, что они твикали буквально все, ради достижения нескольких процентов прироста (благо они использовали Linux в качестве OS узлов их гигантской рендерфермы), они _вообще_ не занимались проблемой фрагментации, сочтя ее незначительной во влиянии на производительность системы хранения в целом.
Безусловно можно придумать такое сочетание рабочих нагрузок и характера хранимых данных, и доступа к ним, когда это будет влиять. Но вопрос, насколько это реальная задача, не уподоблямся ли мы пресловутым сибирским мужикам, которые испытывали новую японскую бензопилу из анегдота. :)
Экстенты существуют по сути только для Exchange (уточнял по документации на 7.3.1, может для более поздних что-то изменилось).
На random чтение влиять не будет, на последовательное для NAS — мало или совсем нет (спасибо NetApp за грамотные алгоритмы кеширования) разве что система и так перегружена, для SAN — вопрос неоднозначный, что там творится на LUN в 3rd party файловой системе хрен его знает, алгоритмы вполне могут не работать (особенно если это какой-нибудь LUN c VMFS нагруженный пачкой VM, а клиент(scsi initiator) по сути один — ESX) или работать частично. Тут NetApp непричем, у всех вендоров будут те же проблемы.
А если считывание LUN идет на уровне Data ONTAP snapmirror например то это уже не SAN вообще.
Про запись уже другой вопрос. На WAFL и RAID-DP фрагментация немного иного характера чем на обычном райде или вообще одном диске. Когда страйп уже записан, а потом часть данных в нем стерта и помечена как свободные блоки то чтобы опять в них записать нужно весь страйп считать(CPread) и опять записать, что в случае WAFL может происходить довольно часто даже для random данных, особенно на заполненной агрегате, особенно на «старой», т.е. тут которую уже давно и интенсивно используют random записями.
WETA ж все-таки по большей части считывали данные (аж FlexCache применили), да и NAS(NFS) у них был.
Вопрос «а почему вы не поставляете, на что надеетесь?» весьма интересен :) Может породить еще и большую кучу малу.
Резюмируя, FUD на то и FUD чтобы нечестно дискредитировать вендора. Реальные проблемы могут быть на старых сильно заполненных (точнее с малым количеством длинных непрерывных свободных мест) агрегатах, где довольно много данных было перезаписано. Либо если неграмотно расширяли (добавляли малое кол-во дисков в райд группы/ создавали новые группы с малым кол-вом) и не делали reallocate после этого.
На random чтение влиять не будет, на последовательное для NAS — мало или совсем нет (спасибо NetApp за грамотные алгоритмы кеширования) разве что система и так перегружена, для SAN — вопрос неоднозначный, что там творится на LUN в 3rd party файловой системе хрен его знает, алгоритмы вполне могут не работать (особенно если это какой-нибудь LUN c VMFS нагруженный пачкой VM, а клиент(scsi initiator) по сути один — ESX) или работать частично. Тут NetApp непричем, у всех вендоров будут те же проблемы.
А если считывание LUN идет на уровне Data ONTAP snapmirror например то это уже не SAN вообще.
Про запись уже другой вопрос. На WAFL и RAID-DP фрагментация немного иного характера чем на обычном райде или вообще одном диске. Когда страйп уже записан, а потом часть данных в нем стерта и помечена как свободные блоки то чтобы опять в них записать нужно весь страйп считать(CPread) и опять записать, что в случае WAFL может происходить довольно часто даже для random данных, особенно на заполненной агрегате, особенно на «старой», т.е. тут которую уже давно и интенсивно используют random записями.
WETA ж все-таки по большей части считывали данные (аж FlexCache применили), да и NAS(NFS) у них был.
Вопрос «а почему вы не поставляете, на что надеетесь?» весьма интересен :) Может породить еще и большую кучу малу.
Резюмируя, FUD на то и FUD чтобы нечестно дискредитировать вендора. Реальные проблемы могут быть на старых сильно заполненных (точнее с малым количеством длинных непрерывных свободных мест) агрегатах, где довольно много данных было перезаписано. Либо если неграмотно расширяли (добавляли малое кол-во дисков в райд группы/ создавали новые группы с малым кол-вом) и не делали reallocate после этого.
> Экстенты существуют по сути только для Exchange (уточнял по документации на 7.3.1, может для более поздних что-то изменилось).
Это у вас путаница. «Экстент» это название метода адресации данных в файловой системе (например NTFS ее тоже использует). WAFL использует экстетнтную модель размещения данных при записи, и это, разумеется, работает для всего, а не только «для Exchange»
> то чтобы опять в них записать нужно весь страйп считать(CPread) и опять записать,
Знаете, это все домыслы, потому что NetApp детали устройства нынешней WAFL не публиковал, поэому все что мы тут с вами на эту тему наспорим будут довольно «из пальца сосаны».
Как там обстоит дело «на самом деле» знают только в NetApp, а они не говорят.
Это у вас путаница. «Экстент» это название метода адресации данных в файловой системе (например NTFS ее тоже использует). WAFL использует экстетнтную модель размещения данных при записи, и это, разумеется, работает для всего, а не только «для Exchange»
> то чтобы опять в них записать нужно весь страйп считать(CPread) и опять записать,
Знаете, это все домыслы, потому что NetApp детали устройства нынешней WAFL не публиковал, поэому все что мы тут с вами на эту тему наспорим будут довольно «из пальца сосаны».
Как там обстоит дело «на самом деле» знают только в NetApp, а они не говорят.
Ок, я вполне верю что это так. Мы говорили про разные extent получается. Я не в курсе был что точно так же называют некий цельный кусок данных расположенный в одном месте.
Не из пальца. Курс PAD (Performance analysis on Data ONTAP) довольно подробно разбирает падение производительности из-за большего количества CPread (Consistency Point read) при записи.
Не из пальца. Курс PAD (Performance analysis on Data ONTAP) довольно подробно разбирает падение производительности из-за большего количества CPread (Consistency Point read) при записи.
А вы можете рассказать о фичах файловой системы WAFL на более прикладном уровне?
Например, мне интересно:
1. Поддерживается ли там квотирование на уровне директорий?
2. Поддерживается ли там фича с отображением пользователю только тех файлов, к которым у него есть доступ (в терминологии MS это называется Access-based Enumeration)?
Например, мне интересно:
1. Поддерживается ли там квотирование на уровне директорий?
2. Поддерживается ли там фича с отображением пользователю только тех файлов, к которым у него есть доступ (в терминологии MS это называется Access-based Enumeration)?
1. Квотирование на уровне пользователей и групп есть для NAS (то есть CIFS и NFS). Квота назначается на некую структуру, которая называется QTree, с точки зрения пользователя эта папка на томе.
Вы создаете qtree, расшариваете ее, и получаете сетевую шару квотированную по объему и, кажется, числу файлов, на юзера/группу.
AD для CIFS поддерживается. Умеет работать с NIS и LDAP для NFS, но подробно последним не занимался, не могу сказать.
2. А это, кажется, никто кроме Novel Netware так и не сделал, кажется.
Обычно это все же как-то иначе реализуется сейчас.
Но свойства «видеть ресурс» или «не видеть» — нет. К сожалению или к счастью ;) не знаю. Не делают это нынче, по моему никто не делает, знаю вот только про Netware.
Доступ (или отсутствие его) к папке или файлу для юзера-группы, есть, конечно, как у обычного файлсервера.
Вы создаете qtree, расшариваете ее, и получаете сетевую шару квотированную по объему и, кажется, числу файлов, на юзера/группу.
AD для CIFS поддерживается. Умеет работать с NIS и LDAP для NFS, но подробно последним не занимался, не могу сказать.
2. А это, кажется, никто кроме Novel Netware так и не сделал, кажется.
Обычно это все же как-то иначе реализуется сейчас.
Но свойства «видеть ресурс» или «не видеть» — нет. К сожалению или к счастью ;) не знаю. Не делают это нынче, по моему никто не делает, знаю вот только про Netware.
Доступ (или отсутствие его) к папке или файлу для юзера-группы, есть, конечно, как у обычного файлсервера.
Вы создаете qtree, расшариваете ее, и получаете сетевую шару квотированную по объему и, кажется, числу файлов, на юзера/группу.А как насчёт вложенных квот? Т.е. на некую расшаренную папку назначается общая квота на группу. А на подпапки внутри неё меньшие квоты для других подгрупп или отдельных пользователей?
А это, кажется, никто кроме Novel Netware так и не сделал, кажется.У Novell на эту фичу был патент, но он то ли истёк, то ли был выкуплен, по крайней мере у MS, начиная с Win2003-R2, это уже было реализовано.
Если это уже сделано в CIFS у MS, почти наверняка это будет со временем и у NetApp, насколько я знаю NetApp использует официальную лицензию MS на CIFS (то есть НЕ Samba).
Насчет квот подробнее сходу не могу сказать, надо в документацию лезть.
Насчет квот подробнее сходу не могу сказать, надо в документацию лезть.
Тут вот мне пишут в ответ на ваш вопрос:
1. Вложенных qtree нет, но если нужно организовать вложенные папки с квотами, то это можно сделать создав qtree (одноуровнево) и организовав их в нужном порядке в дерево с помощью симлинков.
2. -accessbasedenum уже появился.
1. Вложенных qtree нет, но если нужно организовать вложенные папки с квотами, то это можно сделать создав qtree (одноуровнево) и организовав их в нужном порядке в дерево с помощью симлинков.
2. -accessbasedenum уже появился.
MS, кстати, не рекомендует ABE для больших расшаренных папок с большим количеством пользователей, т.к. это дело изрядно подтормаживает в таком случае :)
Прекраснейшая статья! Даже такой дуболом в файловых системах, как я всё понял.Срочно на главную!
Большое спасибо за столь развернутый и в тоже время понятный материал
А вот за этот пост спасибо. В прошлом я бухтел (или это был HP'ный пост?). Сухих постов на харбре не бывает, бывают либо нормальные, либо желтушные-попсовые.
Вы написали нормальный пост.
Вы написали нормальный пост.
Жажду сравнение с GFS2 и ZFS! С графиками!
в кои веки хорошая, годная статья. только не для этого ресурса, это всё равно что бисер перед свиньями метать.
Вот уж действительно вундервафля!
Собственно название оттуда и пошло. Это была такая попытка схохмить и скаламбурить, народ был молодой и веселый.
Изначальная идея, стоящая в основе NetApp — «делать компьютерные стораджи простые в использовании как бытовая техника». Типичное бытовое устройство для американца это тостер. Поэтому исторически нетапповские стораджи принято называт toaster. А что находится внутри тостеров? Вафли. (мы их чаще тостами или гренками зовем, но видимо не нашли подходящей комбинации слов для такой аббревиатуры).
В общем вот такую вот историю возникновения названия старожилы рассказывают
Изначальная идея, стоящая в основе NetApp — «делать компьютерные стораджи простые в использовании как бытовая техника». Типичное бытовое устройство для американца это тостер. Поэтому исторически нетапповские стораджи принято называт toaster. А что находится внутри тостеров? Вафли. (мы их чаще тостами или гренками зовем, но видимо не нашли подходящей комбинации слов для такой аббревиатуры).
В общем вот такую вот историю возникновения названия старожилы рассказывают
«Пустой» блок, который может быть записан он действительно «пустой» или просто может быть записан?
Ну специально его никто не «обнуляет», конечно, как и во всех ныне существующих FS «пустой» блок это такой атрибут файловой системы, принадлежащий данному блоку.
В данном случае это значит, что на этот блок никто (ни файл активной файловой системы, ни снэпшот) не ссылается, и он считается принадлежащим пулу свободных для последующей записи блоков.
Физически это обычно делается с помощью так называемо «битовой карты», если блок используется — там единица, если нет — ноль. Только в случае WAFL используется не «битовая» а «байтовая» карта, потому что блок может принадлежать либо активной файловой системе, либо одному из 256 снэпшотов, на что указывает значние байта. Когда блок не принадлежит никому, то в карте остается только 0, значит он «пуст» (никто не использует), и может быть использован под запись.
В данном случае это значит, что на этот блок никто (ни файл активной файловой системы, ни снэпшот) не ссылается, и он считается принадлежащим пулу свободных для последующей записи блоков.
Физически это обычно делается с помощью так называемо «битовой карты», если блок используется — там единица, если нет — ноль. Только в случае WAFL используется не «битовая» а «байтовая» карта, потому что блок может принадлежать либо активной файловой системе, либо одному из 256 снэпшотов, на что указывает значние байта. Когда блок не принадлежит никому, то в карте остается только 0, значит он «пуст» (никто не использует), и может быть использован под запись.
это точно делали для HDD?
обычно такие фокусы с дописываем делают для флеша с его спецификой больших блоков и стерки
обычно такие фокусы с дописываем делают для флеша с его спецификой больших блоков и стерки
Это делали для HDD, да, ну какой в 93-м году flash. Но и в самом деле, сейчас выяснилось, что такая модель работы прекрасно подходит и для работы с flash.
SSD & WAFL
Может это изначально и не для SSD писалось, но оказалось что запись в новое место очень даже подходит для SSD.
Может это изначально и не для SSD писалось, но оказалось что запись в новое место очень даже подходит для SSD.
гениальные инженерные решения описаные отличным языком.
очень, очень хорошо.
автору большая благодарность.
очень, очень хорошо.
автору большая благодарность.
Спасибо за статью.
Несмотря на то, что довольно давно читаю о NetApp'е, многие «вещи» о WAFL, наконец для меня легли на свои полки.
Несмотря на то, что довольно давно читаю о NetApp'е, многие «вещи» о WAFL, наконец для меня легли на свои полки.
отличная статья, спасибо!)
ну ладно, производительность vs ZFS надо мерять, а как насчет фичастости WAFL vs ZFS?
ну ладно, производительность vs ZFS надо мерять, а как насчет фичастости WAFL vs ZFS?
а про алгоритм L2 кеширования напишете? оч интересно, что у вас вместо ARC.
Э-э. Это про что это, не совсем понял?
Про Performance Acceleration Module разве только?
Что-то про другое L2-кэширование в голову не приходит. Уточните.
Про Performance Acceleration Module разве только?
Что-то про другое L2-кэширование в голову не приходит. Уточните.
Да, наверное про него тоже :)
А в самом сторадже нет кэша для чтения? только nvram для записи/избавления от write hole?
А в самом сторадже нет кэша для чтения? только nvram для записи/избавления от write hole?
Вся установленная в контроллере системы хранения память — это кэш чтения. Кэша записи, в том смысле, в каком это слово используется в других системах просто нет, только буфра OS и пространство NVRAM.
Это связано с тем, что запись производится на диски максимально быстро, и дополнительное кэширование ее почти не улучшает.
Это связано с тем, что запись производится на диски максимально быстро, и дополнительное кэширование ее почти не улучшает.
Э-э. Это про что это, не совсем понял?
Про Performance Acceleration Module разве только?
Что-то про другое L2-кэширование в голову не приходит. Уточните.
Про Performance Acceleration Module разве только?
Что-то про другое L2-кэширование в голову не приходит. Уточните.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Файловая система WAFL — «фундамент» NetApp