RU2449358C1 - Распределенная файловая система и способ управления согласованностью блоков данных в такой системе - Google Patents
Распределенная файловая система и способ управления согласованностью блоков данных в такой системе Download PDFInfo
- Publication number
- RU2449358C1 RU2449358C1 RU2011107514/08A RU2011107514A RU2449358C1 RU 2449358 C1 RU2449358 C1 RU 2449358C1 RU 2011107514/08 A RU2011107514/08 A RU 2011107514/08A RU 2011107514 A RU2011107514 A RU 2011107514A RU 2449358 C1 RU2449358 C1 RU 2449358C1
- Authority
- RU
- Russia
- Prior art keywords
- chunk
- file access
- file
- block
- counter value
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/82—Solving problems relating to consistency
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/88—Monitoring involving counting
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Изобретение относится к области распределенных файловых систем для хранилищ данных большой емкости. Техническим результатом является повышение надежности хранения данных. Согласно способу регистр местоположения файла генерирует значения счетчиков, соответствующие блокам данных (CHUNK), и значения счетчиков одновременно сохраняют на серверах доступа к файлу и в регистре местоположения файла; при записи данных в блок CHUNK клиент доступа к файлу записывает данные и на основной, и на резервные серверы доступа к файлу и изменяет значения счетчиков CHUNK на тех серверах доступа к файлу, где данные записаны нормально; регистр местоположения файла определяет блок CHUNK, счетчик которого имеет максимальное значение, как нормальный и действительный блок согласно соответствующим значениям счетчиков соответствующего блока CHUNK, о которых сообщают основной и резервные серверы доступа к файлу. 2 н. и 9 з.п. ф-лы, 4 ил.
Description
ОБЛАСТЬ ТЕХНИКИ
Данное изобретение относится к распределенной файловой системе для хранилищ данных большой емкости и способу управления такой системой в области компьютерных приложений, и, более конкретно, к файловой системе для крупномасштабной распределенной обработки данных и способу проверки согласованности избыточных резервных блоков данных в такой файловой системе для управления резервированием.
ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ
В известном уровне техники, чтобы гарантировать высокую эффективность обработки данных и централизованное управление метаданными, крупномасштабная файловая система распределенной обработки данных обычно разрабатывается как сервер централизованного управления метаданными (такой как регистр местоположения файла (File Location Register, FLR)) и множество серверов хранения файлов данных (таких как сервер доступа к файлу (File Access Server, FAS)).
Когда пользователь обращается к данным, он, прежде всего, запрашивает у регистра FLR конкретное место хранения данных посредством клиента доступа к файлу (File Access Client, FAC), а затем клиент FAC инициирует запрос на чтение-запись данных конкретному серверу FAS. Сервер FAS управляет файлом данных путем разделения данных файла на отдельные блоки данных (блоки CHUNK), и каждый файл состоит из множества блоков CHUNK. Соответствие блока CHUNK файлу указывается универсальным идентификатором FILEID (идентификатор файла), каждый файл имеет идентификатор FILEID, отличный от других файлов, и идентификатор CHUNKID каждого блока CHUNK состоит из идентификатора FILEID и номера блока CHUNK. Информация о распределении всех блоков CHUNK в файле единообразно помещается в базу данных и управляется регистром FLR.
В кластерной системе большой емкости обычно блоки CHUNK избыточно резервируются, то есть копии одного и того же блока CHUNK хранятся на множестве серверов FAS. Однако в известном уровне техники трудно поддерживать согласованность (совпадение друг с другом) нескольких копий блока CHUNCK, что создает относительно большую проблему, главным образом выраженную в следующем: как гарантировать одновременную запись соответствующих копий на множестве серверов FAS в процессе операции записи; если есть один аномальный или отказавший сервер FAS, как восстановить данные на этом сервере FAS; как гарантировать согласованность записи регистра FLR и сервера FAS во время процесса записи, если регистр FLR находится в аномальном состоянии.
Так как это касается больших блоков CHUNK, общий способ проверки, такой как алгоритм MD5, не может быть применен к блокам CHUNK в известном уровне техники, так как он будет отрицательно влиять на быстродействие при обработке.
Следовательно, известный уровень техники должен быть улучшен и развит.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
В настоящем изобретении предлагается распределенная файловая система и способ управления согласованностью блоков CHUNK для решения вышеупомянутых проблем известного уровня техники и осуществления проверки и необходимого исправления блоков CHUNK для данных большого объема.
Техническая схема данного изобретения включает:
Способ управления согласованностью блоков CHUNK в распределенной файловой системе, который включает следующие шаги:
A) при формировании блока CHUNK регистр местоположения файла генерирует значение счетчика, соответствующее формируемому блоку CHUNK, и сохраняет значение счетчика на серверах доступа к файлу и в регистре местоположения файла;
B) при записи данных в блок CHUNK, клиент доступа к файлу записывает данные в основной и резервный серверы доступа к файлу, и если данные успешно записаны и в основной и в резервный серверы доступа к файлу, клиент доступа к файлу не изменяет значения счетчика блока CHUNK; в ином случае клиент доступа к файлу увеличивает с заранее заданным размером шага значение счетчика CHUNK на тех серверах доступа к файлу, где данные были записаны успешно;
С) упомянутый регистр местоположения файла на основании значений счетчика соответствующего блока CHUNK, о которых сообщают основной и резервные серверы доступа к файлу, определяет блок CHUNK, значение счетчика которого максимально, как нормальный и действительный блок CHUNK, и исправляет аномальные блоки CHUNK.
Кроме того, способ может включать следующее:
при изменении данных блока CHUNK регистр местоположения файла возвращает упомянутому клиенту доступа к файлу информацию основного и резервного серверов доступа к файлу, на которых находится блок CHUNK, и упомянутый клиент доступа к файлу инициирует операцию изменения данных для упомянутых основного и резервного серверов доступа к файлу;
если данные изменены успешно и на основном и на резервном серверах доступа к файлу, клиент доступа к файлу не изменяет значение счетчика CHUNK; в ином случае клиент доступа к файлу увеличивает с заранее заданным размером шага значение счетчика измененного блока CHUNK на том сервере доступа к файлу, где данные были изменены успешно.
Кроме того, в способе упомянутый заранее заданный размер шага может быть равен 1.
Кроме того, в способе упомянутый шаг С может дополнительно включать следующее: регистр местоположения файла посылает запрос на проверку блока CHUNK упомянутым серверам доступа к файлу в момент времени запуска и через определенный временной интервал.
Кроме того, упомянутый способ может дополнительно включать процесс проверки блока CHUNK, при этом процесс проверки блока CHUNK включает:
D1) упомянутые серверы доступа к файлу сообщают обо всех локальных идентификаторах CHUNKID регистру местоположения файла, и регистр местоположения файла создает хэш-таблицу HASH с идентификаторами CHUNKID, принятыми впервые, и для принимаемого впоследствии идентификатора CHUNKID ищет в хэш-таблице HASH идентификатор CHUNKID, совпадающий с упомянутым принимаемым впоследствии идентификатором CHUNKID, и если в хэш-таблице HASH есть идентификатор CHUNKID, совпадающий с принимаемым впоследствии идентификатором CHUNKID, то это означает, что блоки CHUNK являются группой из основного и резервного блоков CHUNK;
D2) регистр местоположения файла записывает все группы идентификаторов CHUNKID и проверяет каждый блок CHUNK.
Кроме того, в способе регистр местоположения файла может определять основной и резервный серверы доступа к файлу, хранящие копии одного и того же блока CHUNK, как одну группу, и делить все серверы доступа к файлу в системе на множество групп.
Кроме того, в способе упомянутый шаг проверки блоков CHUNK, соответствующих каждой группе идентификаторов CHUNKID, на шаге D2 может включать:
D21) проверку, имеют ли проверяемые блоки CHUNK запись в регистре местоположения файла; и немедленное удаление проверяемых блоков CHUNK с серверов доступа к файлу, если не имеют; в ином случае - переход к шагу D22;
D22) сравнение значений счетчика соответствующих блоков CHUNK в базе данных регистра местоположения файла и каждого сервера доступа к файлу, и определение блока CHUNK с максимальным значением счетчика в качестве действительного блока CHUNK.
Кроме того, в способе шаг D2 может дополнительно включать следующее:
если значение счетчика блока CHUNK в регистре местоположения файла максимально, то запись блока CHUNK из базы данных регистра местоположения удаляют.
Кроме того, в способе шаг D2 может дополнительно включать следующее:
если имеется сервер доступа к файлу, на котором значение счетчика CHUNK является максимальным, регистр местоположения файла посылает запрос на исправление блока CHUNK другим серверам доступа к файлу, на которых значение счетчика CHUNK является меньшим, и копирует данные действительного блока CHUNK в аномальный блок CHUNK;
после того, как данные скопированы, значение счетчика блока CHUNK на каждом сервере доступа к файлу изменяется так, чтобы сделать значение счетчика совпадающим с максимальным значением счетчика.
Кроме того, в способе шаг D2 может дополнительно включать следующее:
если значение счетчика блока CHUNK в регистре местоположения файла является меньшим, чем на упомянутых серверах доступа к файлу, значение счетчика CHUNK в базе данных регистра местоположения файла изменяют синхронно.
Распределенная файловая система, включающая по меньшей мере один сервер доступа к файлу и по меньшей мере один регистр местоположения файла, связанные посредством сети; упомянутый сервер доступа к файлу подключается к хранилищу данных; пользователь посылает запрос на запись данных серверу доступа к файлу и регистру местоположения файла посредством клиента доступа к файлу, и увеличивает с заранее заданным размером шага значение счетчика блока CHUNK на том файловом сервере, где данные записаны нормально; причем упомянутый сервер доступа к файлу сконфигурирован по меньшей мере с основным и резервным серверами доступа к файлу; и
регистр местоположения файла используется для генерирования значения счетчика, соответствующего блоку CHUNK, и управления исправлением для аномальных блоков CHUNK согласно значению счетчика CHUNK, о котором сообщают основной и резервный серверы доступа к файлу.
Применение счетчика блока CHUNK в распределенной файловой системе и применение способа управления согласованностью блоков CHUNK согласно настоящему изобретению для проверки нормальности и необходимости исправления каждого блока CHUNK позволяет легко и эффективно управлять резервными блоками CHUNK в большой кластерной системе и поддерживать ее согласованность, более того, появляется возможность исправлять аномальный резервный блок CHUNK, при этом данная реализация является простой и точной.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Фиг.1 - блок-схема изменения значения счетчика блока CHUNK согласно способу настоящего изобретения при записи или изменении данных.
Фиг.2 - блок-схема приема и проверки регистром FLR блоков CHUNK, о которых сообщает сервер FAS, в соответствии со способом настоящего изобретения.
Фиг.3 - блок-схема частного способа проверки посредством регистра FLR в соответствии со способом настоящего изобретения.
Фиг.4 иллюстрирует структуру распределенной файловой системы в соответствии с настоящим изобретением.
ПРЕДПОЧТИТЕЛЬНЫЕ ФОРМЫ ОСУЩЕСТВЛЕНИЯ НАСТОЯЩЕГО ИЗОБРЕТЕНИЯ
Каждая предпочтительная форма осуществления данного изобретения будет подробно описана со ссылкой на прилагаемые чертежи.
Данное изобретение раскрывает распределенную файловую систему и способ управления согласованностью блоков CHUNK с использованием концепции счетчика блока CHUNK, при этом каждый блок CHUNK снабжается счетчиком для указания количества изменений блока CHUNK. Значение счетчика увеличивается, с заранее заданным размером шага, каждый раз при изменении блока CHUNK, поэтому, если значения счетчика основного и резервного блоков CHUNK не совпадают, это означает, что имеется недействительный блок CHUNK, и аномальные блоки CHUNK соответственно исправляют.
Способ данного изобретения решает проблему управления главным и резервным блоками CHUNK, и его основная реализация включает следующее.
При формировании блоков CHUNK эти блоки единообразно формируются регистром FLR, и значение счетчика первоначально созданного блока CHUNK равно 1. Это значение сохраняется также на сервере FAS и в регистре FLR.
Для упрощения описания рассмотрим случай, когда используется один основной и один резервный серверы FAS. Например, для иллюстрации, как показано на фиг.1, в процессе инициирования пользователем процесса записи данных блока CHUNK клиент FAC одновременно записывает две копии данных в основной и резервный серверы FAS, соответственно, и если запись как в основной, так и в резервный серверы FAS является успешной, процесс изменения счетчика CHUNK не инициируется. Если происходит отклонение при записи данных в некоторый сервер FAS, клиент FAC начинает процесс изменения счетчика для нормального сервера FAS, чтобы изменить текущее значение счетчика нормального блока CHUNK. Следовательно, значения счетчика блоков CHUNK на основном и резервном серверах FAS не будут одинаковы, и значение счетчика нормального блока CHUNK будет больше. На более поздней стадии аномальный блок CHUNK может быть определен простой проверкой, и этот блок CHUNK исправляют на аномальном сервере FAS.
Когда пользователь инициирует изменение контента файла, регистр FLR возвращает клиенту FAC информацию двух серверов FAS, на которых располагается соответствующий блок CHUNK, и клиент FAC немедленно начинает операцию изменения данных для двух серверов FAS. Если и основной, и резервный серверы FAS успешно изменяют данные, процесс изменения счетчика CHUNK не инициируют. Если при записи данных на некоторый сервер FAS происходит отклонение, клиент FAC инициирует процесс изменения счетчика CHUNK для нормального сервера FAS, чтобы увеличить, с заранее заданным размером шага, значение счетчика соответствующего блока CHUNK на упомянутом сервере FAS, и одновременно увеличивает значение счетчика блока CHUNK в регистре FLR. Таким образом, значения счетчика блоков CHUNK на основном и резервном серверах FAS становятся неодинаковыми. Аномальный блок CHUNK может быть определен простой проверкой на более поздней стадии путем сравнения значений счетчика, и блок CHUNK исправляют на аномальном сервере FAS.
С помощью вышеупомянутого процесса можно гарантировать, что в случае сбоя значения счетчика блоков CHUNK на основном и резервном серверах FAS обязательно будут различными. Регистр FLR инициирует запрос на проверку блока CHUNK серверу FAS в момент запуска и через определенный временной интервал. В соответствии со значениями счетчика блоков CHUNK, о которых сообщают основной и резервный серверы FAS, регистр FLR может определить сервер FAS, на котором блок CHUNK является правильным, с максимальным значением счетчика, в качестве основы для определения, и таким образом, блоки CHUNK на аномальном сервере FAS могут быть исправлены.
Ниже способ управления согласованностью блоков CHUNK в распределенной файловой системе согласно данному изобретению будет проиллюстрирован примерами:
Определим идентификатор CHUNKID (идентификатор блока CHUNK) как: FILEID (идентификатор файла, 4-байтовое целое число без знака)+нумерация CHUNK (2-байтовое целое число без знака) + счетчик (4-байтовое целое число без знака); на стороне регистра FLR имеется база данных для хранения каждого идентификатора CHUNKID, содержащая значение счетчика CHUNK и информацию о местоположении сервера FAS, на котором находится упомянутый блок CHUNK; каждый блок CHUNK хранится на сервере FAS, и значение счетчика CHUNK записывается на стороне сервера FAS.
Как показано на фиг.1, когда пользователь начинает процесс записи, клиент FAC, прежде всего, обращается к регистру FLR для назначения всех серверов FAS, которые имеют отношение к резервированию. После успешного назначения регистр FLR записывает идентификатор CHUNKID в локальную базу данных, и начальное значение счетчика CHUNK устанавливается на 1.
Клиент FAC непосредственно посылает запрос на запись данных двум серверам FAS. Когда клиент FAC записывает данные, он непрерывно отчитывается о состоянии записи каждого сервера FAS. Сообщаемая информация о состоянии включает идентификатор ID записываемого в данное время блока CHUNK и состояние записи каждого сервера FAS.
После того как регистр FLR принимает сообщения о состоянии, он сравнивает состояния записи двух серверов FAS, и если все они являются нормальными, то никакая обработка не требуется; если оба сервера FAS является аномальными, значения счетчика CHUNK в регистре FLR немедленно увеличивают; если обнаружено, что состояние записи одного сервера FAS аномально, в то время как состояние другого является нормальным, регистр FLR инициирует запрос на изменение счетчика CHUNK нормальному серверу FAS. После того как упомянутый нормальный сервер FAS принимает запрос, он увеличивает значение счетчика, соответствующее локальному блоку CHUNK, и возвращает сообщение об успехе изменения регистру FLR. После того как регистр FLR принимает сообщение об успехе изменения, он изменяет значение в локальной базе данных на значение нормального сервера FAS, в то время как сообщаемое аномальным сервером FAS значение счетчика блока CHUNK не будет изменено.
Когда пользователь инициирует изменение, процедура обработки аналогична вышеописанному процессу. Отличие заключается в том, что когда записываются новые данные, регистр FLR возвращает информацию того сервера FAS, на котором находится новый блок CHUNK, или информацию сервера FAS, который уже имеет данные.
Регистр FLR инициирует процесс запроса на проверку блока CHUNK для сервера FAS в момент запуска и через некоторый интервал времени, как показано на фиг.2. Способ проверки заключается в следующем: регистр FLR рассматривает каждые основной и резервный серверы FAS как пару, и полный кластер блоков CHUNK разделяется на несколько пар, например на N пар. Для каждой пары запрос на проверку посылается каждому члену пары, при этом сервер FAS, который принял запрос, сообщает все локальные идентификаторы CHUNKID регистру FLR, и регистр FLR помещает информацию первого принятого CHUNKID в хэш-таблицу HASH и выполняет поиск в хэш-таблице HASH после приема последующего идентификатора CHUNKID, и если он находит идентификатор CHUNKID в таблице, это означает, что они составляют пару из основного и резервного блоков CHUNK.
Если регистр FLR не находит принятый идентификатор CHUNKID в хэш-таблице HASH, это может быть связано с тем, что эти основной и резервный идентификаторы CHUNKID некомплектны; делают запись всех пар информации CHUNKID одновременно, и после того, как пара членов успешно проверяется, регистр FLR проверяет информацию каждого идентификатора CHUNKID. Процесс проверки показан на фиг.3, и этот процесс включает:
Шаг первый: проверяют наличие записи блока CHUNK в регистре FLR и немедленно удаляют блок CHUNK, если запись отсутствует, в другом случае продолжают проверку;
Шаг второй: вычисляют значение счетчика блока CHUNK в базе данных FLR и на каждом сервере FAS, сравнивают их для получения максимального значения и принимают блок CHUNK с максимальным значением счетчика в качестве действительного и нормального.
Шаг третий: проверяют значение счетчика CHUNK, и данный процесс включает следующее:
Если значение счетчика блока CHUNK в регистре FLR является максимальным, это означает, что данные блока CHUNK на всех серверах FAS ненадежны и необходимо удалить запись блока CHUNK из базы данных FLR.
Если есть сервер FAS, имеющий максимальное значение счетчика блока CHUNK, регистр FLR инициирует запрос на исправление блока CHUNK всем серверам FAS, на которых блок CHUNK имеет меньшее значение счетчика, то есть сообщает серверу FAS, на котором значение счетчика является максимальным, что определенный блок CHUNK, находящийся на нем, должен быть скопирован с этого локального сервера на аномальные серверы FAS. После завершения копирования значение счетчика соответствующего блока CHUNK на каждом сервере FAS немедленно изменяется, чтобы сделать его совпадающим с максимальным значением.
Если значение счетчика блока CHUNK в регистре FLR меньше этого значения на серверах FAS, регистр FLR должен изменить значение счетчика CHUNK в базе данных FLR.
На фиг.4 показана структура распределенной файловой системы в соответствии с настоящим изобретением, и эта система содержит по меньшей мере один сервер 401 доступа к файлу и по меньшей мере один регистр 402 местоположения файла, которые связаны посредством сети, такой как локальная сеть Ethernet, при этом каждый сервер 401 доступа к файлу подключен также к соответствующему хранилищу 411 данных, по меньшей мере один регистр 402 местоположения файла используется для генерирования значения счетчика соответствующего блока CHUNK во время операции записи данных для сервера 401 доступа к файлу. Пользователь посылает запрос на доступ к данным соответствующему серверу 401 доступа к файлу и регистру 402 местоположения файла посредством упомянутого клиента 403 доступа к файлу; сервер 401 доступа к файлу конфигурируется по меньшей мере с основным и резервным серверами доступа к файлу, и клиент 403 доступа к файлу используется для записи данных в соответствующий блок CHUNK на основном и резервном серверах доступа к файлу и для увеличения значения счетчика блока CHUNK с заранее заданным размером шага на том сервере доступа к файлу, на котором запись данных является нормальной; регистр 402 местоположения файла используется для определения, является ли блок CHUNK аномальным, в соответствии с тем, совпадают ли значения счетчика соответствующих блоков CHUNK, сообщенные основным и резервным серверами доступа к файлу, а также используется для управления исправлением аномальных блоков CHUNK.
Распределенная файловая система и способ управления согласованностью блоков CHUNK в соответствии с данным изобретением позволяют легко и эффективно управлять избыточными резервными блоками CHUNK в кластерной системе большой емкости, чтобы поддерживать их согласованность и исправлять аномальные резервные блоки CHUNK. Это обеспечено главным образом тем, что:
1. Если в процессе сохранения данных пользователем (дозаписи или изменения данных) один из основного и резервного серверов FAS является аномальным, значение счетчика блока CHUNK на нормальном сервере FAS увеличивают, в то время как значение счетчика блока CHUNK на аномальном сервере FAS не изменяют; и, когда позже регистр FLR выполняет проверки синхронизации, он удаляет с сервера FAS блок CHUNK, значение счетчика которого является меньшим, согласно проверке значения счетчика блока CHUNK, и исправляет соответствующие блоки CHUNK на аномальном сервере FAS на основе блоков CHUNK нормального сервера FAS.
2. Согласно способу настоящего изобретения, блок CHUNK, значение счетчика которого максимально, принимают в качестве нормального и действительного, и если значение, записанное в регистре FLR, максимально, то это означает, что блоки CHUNK на всех серверах FAS ненадежны; если значение, записанное на одном сервере FAS, максимально, то необходимо исправить этот блок CHUNK на тех серверах FAS, на которых это значение меньше, и одновременно изменить запись в регистре FLR.
Из вышеприведенного описания можно видеть, что распределенная файловая система и способ управления согласованностью блоков CHUNK в соответствии с данным изобретением могут быть легко и точно реализованы; проверка и вычисление являются очень быстрыми и подходящими для обработки больших блоков CHUNK.
Очевидно, что представленное выше описание предпочтительных форм осуществления данного изобретения является описанием конкретных вариантов осуществления и не должно рассматриваться как ограничение объема настоящего изобретения, который определяется прилагаемой формулой изобретения.
ПРОМЫШЛЕННАЯ ПРИМЕНИМОСТЬ
Распределенная файловая система и способ управления согласованностью блоков CHUNK, предлагаемые в настоящем изобретении, применяют счетчик блока CHUNK для определения, является ли блок CHUNK аномальным, или должен ли блок CHUNK быть исправлен, и в большой кластерной системе эти система и способ позволяют легко и эффективно управлять избыточными резервными блоками CHUNK и поддерживать их согласованность, кроме того, появляется возможность исправлять аномальные резервные блоки CHUNK, при этом реализация предложенных системы и способа является простой и точной.
Claims (11)
1. Способ управления согласованностью блоков CHUNK в распределенной файловой системе, включающий следующие шаги:
A) при формировании блока CHUNK регистр местоположения файла генерирует значение счетчика, соответствующее формируемому блоку CHUNK, и сохраняет значение счетчика на серверах доступа к файлу и в регистре местоположения файла;
B) при записи данных в блок CHUNK клиент доступа к файлу записывает данные в основной и резервный серверы доступа к файлу, и если данные успешно записаны и в основной, и в резервный серверы доступа к файлу, клиент доступа к файлу не изменяет значение счетчика блока CHUNK, в который записаны данные; в ином случае клиент доступа к файлу увеличивает с заранее заданным размером шага значение счетчика блока CHUNK, в который записаны данные на тех серверах доступа к файлу, где данные записаны успешно;
C) упомянутый регистр местоположения файла на основании значений счетчика текущего блока CHUNK, о которых сообщают соответственно основной и резервный серверы доступа к файлу, определяет блок CHUNK сервера доступа к файлу, значение счетчика которого максимально, как нормальный и действительный блок CHUNK, и определяет блоки CHUNK других серверов доступа к файлу как аномальные блоки CHUNK и исправляет аномальные блоки CHUNK.
A) при формировании блока CHUNK регистр местоположения файла генерирует значение счетчика, соответствующее формируемому блоку CHUNK, и сохраняет значение счетчика на серверах доступа к файлу и в регистре местоположения файла;
B) при записи данных в блок CHUNK клиент доступа к файлу записывает данные в основной и резервный серверы доступа к файлу, и если данные успешно записаны и в основной, и в резервный серверы доступа к файлу, клиент доступа к файлу не изменяет значение счетчика блока CHUNK, в который записаны данные; в ином случае клиент доступа к файлу увеличивает с заранее заданным размером шага значение счетчика блока CHUNK, в который записаны данные на тех серверах доступа к файлу, где данные записаны успешно;
C) упомянутый регистр местоположения файла на основании значений счетчика текущего блока CHUNK, о которых сообщают соответственно основной и резервный серверы доступа к файлу, определяет блок CHUNK сервера доступа к файлу, значение счетчика которого максимально, как нормальный и действительный блок CHUNK, и определяет блоки CHUNK других серверов доступа к файлу как аномальные блоки CHUNK и исправляет аномальные блоки CHUNK.
2. Способ по п.1, дополнительно включающий:
при изменении данных блока CHUNK регистр местоположения файла возвращает клиенту доступа к файлу информацию основного и резервного серверов доступа к файлу, на которых находится блок CHUNK, требующий изменения, и упомянутый клиент доступа к файлу инициирует операцию изменения данных для основного и резервного серверов доступа к файлу;
если операция изменения данных и для основного, и для резервного серверов доступа к файлу успешна, клиент доступа к файлу не изменяет значение счетчика измененного блока CHUNK; в ином случае клиент доступа к файлу увеличивает с заранее заданным размером шага значение счетчика измененного блока CHUNK на том сервере доступа к файлу, для которого операция изменения данных является успешной.
при изменении данных блока CHUNK регистр местоположения файла возвращает клиенту доступа к файлу информацию основного и резервного серверов доступа к файлу, на которых находится блок CHUNK, требующий изменения, и упомянутый клиент доступа к файлу инициирует операцию изменения данных для основного и резервного серверов доступа к файлу;
если операция изменения данных и для основного, и для резервного серверов доступа к файлу успешна, клиент доступа к файлу не изменяет значение счетчика измененного блока CHUNK; в ином случае клиент доступа к файлу увеличивает с заранее заданным размером шага значение счетчика измененного блока CHUNK на том сервере доступа к файлу, для которого операция изменения данных является успешной.
3. Способ по п.2, отличающийся тем, что упомянутый заранее заданный размер шага равен 1.
4. Способ по п.3, отличающийся тем, что упомянутый шаг С дополнительно включает:
посылку упомянутым регистром местоположения файла запроса на проверку блока CHUNK упомянутым серверам доступа к файлу в момент запуска и через определенный временной интервал.
посылку упомянутым регистром местоположения файла запроса на проверку блока CHUNK упомянутым серверам доступа к файлу в момент запуска и через определенный временной интервал.
5. Способ по п.4, дополнительно включающий процесс проверки блока CHUNK, при этом процесс проверки блока CHUNK включает следующее:
D1) упомянутые серверы доступа к файлу сообщают обо всех локальных идентификаторах CHUNKID регистру местоположения файла, и регистр местоположения файла создает хэш-таблицу HASH с идентификаторами CHUNKID, принятыми впервые, а для принимаемого впоследствии идентификатора CHUNKID ищет в хэш-таблице HASH идентификатор CHUNKID, совпадающий с упомянутым принимаемым впоследствии идентификатором CHUNKID, и если в хэш-таблице HASH есть идентификатор CHUNKID, совпадающий с принимаемым впоследствии идентификатором CHUNKID, то определяет блоки CHUNK, соответствующие совпадающим идентификаторам CHUNKID, как группу из основного и резервного блоков CHUNK;
D2) регистр местоположения файла записывает все группы идентификаторов CHUNKID и проверяет блоки CHUNK, соответствующие каждой группе идентификаторов CHUNKID.
D1) упомянутые серверы доступа к файлу сообщают обо всех локальных идентификаторах CHUNKID регистру местоположения файла, и регистр местоположения файла создает хэш-таблицу HASH с идентификаторами CHUNKID, принятыми впервые, а для принимаемого впоследствии идентификатора CHUNKID ищет в хэш-таблице HASH идентификатор CHUNKID, совпадающий с упомянутым принимаемым впоследствии идентификатором CHUNKID, и если в хэш-таблице HASH есть идентификатор CHUNKID, совпадающий с принимаемым впоследствии идентификатором CHUNKID, то определяет блоки CHUNK, соответствующие совпадающим идентификаторам CHUNKID, как группу из основного и резервного блоков CHUNK;
D2) регистр местоположения файла записывает все группы идентификаторов CHUNKID и проверяет блоки CHUNK, соответствующие каждой группе идентификаторов CHUNKID.
6. Способ по п.5, отличающийся тем, что
регистр местоположения файла определяет основной и резервный серверы доступа к файлу, хранящие копии одного и того же блока CHUNK, как одну группу, и делит все серверы доступа к файлу в системе на множество групп.
регистр местоположения файла определяет основной и резервный серверы доступа к файлу, хранящие копии одного и того же блока CHUNK, как одну группу, и делит все серверы доступа к файлу в системе на множество групп.
7. Способ по п.5, отличающийся тем, что упомянутый шаг проверки блоков CHUNK, соответствующих каждой группе идентификаторов CHUNKID, на шаге D2 включает:
D21) проверку, имеют ли проверяемые блоки CHUNK запись в упомянутом регистре местоположения файла; и немедленное удаление блоков CHUNK с серверов доступа к файлу, если не имеют; в ином случае - переход к шагу D22;
D22) сравнение значений счетчика проверяемых блоков CHUNK в регистре местоположения файла и на каждом сервере доступа к файлу, и определение блока CHUNK с максимальным значением счетчика в качестве действительного блока CHUNK.
D21) проверку, имеют ли проверяемые блоки CHUNK запись в упомянутом регистре местоположения файла; и немедленное удаление блоков CHUNK с серверов доступа к файлу, если не имеют; в ином случае - переход к шагу D22;
D22) сравнение значений счетчика проверяемых блоков CHUNK в регистре местоположения файла и на каждом сервере доступа к файлу, и определение блока CHUNK с максимальным значением счетчика в качестве действительного блока CHUNK.
8. Способ по п.7, отличающийся тем, что
если значение счетчика проверяемого блока CHUNK в упомянутом регистре местоположения файла максимально, запись блока CHUNK удаляют из базы данных упомянутого регистра местоположения файла.
если значение счетчика проверяемого блока CHUNK в упомянутом регистре местоположения файла максимально, запись блока CHUNK удаляют из базы данных упомянутого регистра местоположения файла.
9. Способ по п.7, отличающийся тем, что
если имеется сервер доступа к файлу, на котором значение счетчика проверяемого блока CHUNK является максимальным, регистр местоположения файла посылает запрос на исправление блока CHUNK другим серверам доступа к файлу, на которых значение счетчика блока CHUNK является меньшим, и копирует блок CHUNK с сервера с максимальным значением счетчика на сервер с меньшим значением счетчика;
после того, как данные скопированы, значение счетчика проверяемого блока CHUNK на каждом сервере доступа к файлу изменяют так, чтобы сделать значение счетчика совпадающим с максимальным значением счетчика.
если имеется сервер доступа к файлу, на котором значение счетчика проверяемого блока CHUNK является максимальным, регистр местоположения файла посылает запрос на исправление блока CHUNK другим серверам доступа к файлу, на которых значение счетчика блока CHUNK является меньшим, и копирует блок CHUNK с сервера с максимальным значением счетчика на сервер с меньшим значением счетчика;
после того, как данные скопированы, значение счетчика проверяемого блока CHUNK на каждом сервере доступа к файлу изменяют так, чтобы сделать значение счетчика совпадающим с максимальным значением счетчика.
10. Способ по п.7, отличающийся тем, что
если значение счетчика проверяемого блока CHUNK в регистре местоположения файла является меньшим, чем на упомянутых серверах доступа к файлу, значение счетчика проверяемого блока CHUNK в базе данных базы проверяемого регистра местоположения файла изменяют синхронно.
если значение счетчика проверяемого блока CHUNK в регистре местоположения файла является меньшим, чем на упомянутых серверах доступа к файлу, значение счетчика проверяемого блока CHUNK в базе данных базы проверяемого регистра местоположения файла изменяют синхронно.
11. Распределенная файловая система, включающая по меньшей мере один сервер доступа к файлу и по меньшей мере один регистр местоположения файла, связанные посредством сети; при этом сервер доступа к файлу подключен к хранилищу данных; и когда пользователь посылает запрос на запись данных упомянутому серверу доступа к файлу и регистру местоположения файла посредством клиента доступа к файлу, значение счетчика CHUNK увеличивается с заранее заданным размером шага на том сервере доступа к файлу, где данные записаны нормально; при этом упомянутый сервер доступа к файлу сконфигурирован по меньшей мере с основным и резервным серверами доступа к файлу; и
регистр местоположения файла используется для генерирования значения счетчика, соответствующего блоку CHUNK, и управления исправлением аномальных блоков CHUNK в соответствии со значением счетчика блока CHUNK, о котором сообщают основной и резервный серверы доступа к файлу.
регистр местоположения файла используется для генерирования значения счетчика, соответствующего блоку CHUNK, и управления исправлением аномальных блоков CHUNK в соответствии со значением счетчика блока CHUNK, о котором сообщают основной и резервный серверы доступа к файлу.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008101422912A CN101334797B (zh) | 2008-08-04 | 2008-08-04 | 一种分布式文件***及其数据块一致性管理的方法 |
| CN200810142291.2 | 2008-08-04 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| RU2449358C1 true RU2449358C1 (ru) | 2012-04-27 |
Family
ID=40197395
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2011107514/08A RU2449358C1 (ru) | 2008-08-04 | 2009-07-30 | Распределенная файловая система и способ управления согласованностью блоков данных в такой системе |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US8285689B2 (ru) |
| EP (1) | EP2330519A4 (ru) |
| CN (1) | CN101334797B (ru) |
| RU (1) | RU2449358C1 (ru) |
| WO (1) | WO2010015143A1 (ru) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2653278C2 (ru) * | 2012-08-03 | 2018-05-07 | ЗэтТиИ Корпорейшн | Способ и устройство хранения для распределенной файловой системы |
| RU2686594C2 (ru) * | 2014-05-11 | 2019-04-29 | МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи | Файловая служба, использующая интерфейс совместного файлового доступа и передачи состояния представления |
| RU2696212C1 (ru) * | 2018-01-30 | 2019-07-31 | Леонид Евгеньевич Посадсков | Способ обеспечения защищенной передачи данных в облачных хранилищах с использованием частичных образов |
| RU2754189C2 (ru) * | 2016-12-19 | 2021-08-30 | Свирлдз, Инк. | Способы и устройство для распределенной базы данных, которая позволяет удалять события |
| US11232081B2 (en) | 2015-08-28 | 2022-01-25 | Swirlds, Inc. | Methods and apparatus for a distributed database within a network |
| US11256823B2 (en) | 2017-07-11 | 2022-02-22 | Swirlds, Inc. | Methods and apparatus for efficiently implementing a distributed database within a network |
| RU2776826C2 (ru) * | 2016-12-19 | 2022-07-27 | Свирлдз, Инк. | Способы и устройство для распределенной базы данных, которая позволяет удалять события |
| US11475150B2 (en) | 2019-05-22 | 2022-10-18 | Hedera Hashgraph, Llc | Methods and apparatus for implementing state proofs and ledger identifiers in a distributed database |
| US11537593B2 (en) | 2017-11-01 | 2022-12-27 | Hedera Hashgraph, Llc | Methods and apparatus for efficiently implementing a fast-copyable database |
| US11677550B2 (en) | 2016-11-10 | 2023-06-13 | Hedera Hashgraph, Llc | Methods and apparatus for a distributed database including anonymous entries |
| US11734260B2 (en) | 2015-08-28 | 2023-08-22 | Hedera Hashgraph, Llc | Methods and apparatus for a distributed database within a network |
| US11797502B2 (en) | 2015-08-28 | 2023-10-24 | Hedera Hashgraph, Llc | Methods and apparatus for a distributed database within a network |
Families Citing this family (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE102008018680A1 (de) * | 2007-12-18 | 2009-07-02 | Siemens Aktiengesellschaft | Verfahren zum Unterstützen eines sicherheitsgerichteten Systems |
| CN101334797B (zh) * | 2008-08-04 | 2010-06-02 | 中兴通讯股份有限公司 | 一种分布式文件***及其数据块一致性管理的方法 |
| US8849939B2 (en) * | 2011-12-02 | 2014-09-30 | International Business Machines Corporation | Coordinating write sequences in a data storage system |
| CN102750322B (zh) * | 2012-05-22 | 2014-11-05 | 中国科学院计算技术研究所 | 一种机群文件***分布式元数据一致性保证方法和*** |
| CN102890716B (zh) * | 2012-09-29 | 2017-08-08 | 南京中兴新软件有限责任公司 | 分布式文件***和分布式文件***的数据备份方法 |
| CN103729436A (zh) * | 2013-12-27 | 2014-04-16 | 中国科学院信息工程研究所 | 一种分布式元数据管理方法及*** |
| US9292389B2 (en) * | 2014-01-31 | 2016-03-22 | Google Inc. | Prioritizing data reconstruction in distributed storage systems |
| US9779015B1 (en) | 2014-03-31 | 2017-10-03 | Amazon Technologies, Inc. | Oversubscribed storage extents with on-demand page allocation |
| US9449008B1 (en) | 2014-03-31 | 2016-09-20 | Amazon Technologies, Inc. | Consistent object renaming in distributed systems |
| US10372685B2 (en) | 2014-03-31 | 2019-08-06 | Amazon Technologies, Inc. | Scalable file storage service |
| US9772787B2 (en) | 2014-03-31 | 2017-09-26 | Amazon Technologies, Inc. | File storage using variable stripe sizes |
| US9274710B1 (en) | 2014-03-31 | 2016-03-01 | Amazon Technologies, Inc. | Offset-based congestion control in storage systems |
| US9569459B1 (en) | 2014-03-31 | 2017-02-14 | Amazon Technologies, Inc. | Conditional writes at distributed storage services |
| US9294558B1 (en) | 2014-03-31 | 2016-03-22 | Amazon Technologies, Inc. | Connection re-balancing in distributed storage systems |
| US9495478B2 (en) | 2014-03-31 | 2016-11-15 | Amazon Technologies, Inc. | Namespace management in distributed storage systems |
| US10264071B2 (en) | 2014-03-31 | 2019-04-16 | Amazon Technologies, Inc. | Session management in distributed storage systems |
| US9602424B1 (en) | 2014-03-31 | 2017-03-21 | Amazon Technologies, Inc. | Connection balancing using attempt counts at distributed storage systems |
| US9519510B2 (en) | 2014-03-31 | 2016-12-13 | Amazon Technologies, Inc. | Atomic writes for multiple-extent operations |
| CN105335250B (zh) * | 2014-07-28 | 2018-09-28 | 浙江大华技术股份有限公司 | 一种基于分布式文件***的数据恢复方法及装置 |
| US10108624B1 (en) | 2015-02-04 | 2018-10-23 | Amazon Technologies, Inc. | Concurrent directory move operations using ranking rules |
| CN104699771B (zh) * | 2015-03-02 | 2019-09-20 | 北京京东尚科信息技术有限公司 | 数据同步方法和集群节点 |
| US9860317B1 (en) | 2015-04-30 | 2018-01-02 | Amazon Technologies, Inc. | Throughput throttling for distributed file storage services with varying connection characteristics |
| US10346367B1 (en) | 2015-04-30 | 2019-07-09 | Amazon Technologies, Inc. | Load shedding techniques for distributed services with persistent client connections to ensure quality of service |
| CN105426483B (zh) * | 2015-11-19 | 2019-01-11 | 华为技术有限公司 | 一种基于分布式***的文件读取方法及装置 |
| US10545927B2 (en) | 2016-03-25 | 2020-01-28 | Amazon Technologies, Inc. | File system mode switching in a distributed storage service |
| US10474636B2 (en) | 2016-03-25 | 2019-11-12 | Amazon Technologies, Inc. | Block allocation for low latency file systems |
| US10140312B2 (en) | 2016-03-25 | 2018-11-27 | Amazon Technologies, Inc. | Low latency distributed storage service |
| CN105892954A (zh) * | 2016-04-25 | 2016-08-24 | 乐视控股（北京）有限公司 | 基于多副本的数据存储方法和装置 |
| CN108241548A (zh) * | 2016-12-23 | 2018-07-03 | 航天星图科技（北京）有限公司 | 一种基于分布式***的文件读取方法 |
| CN107071031B (zh) * | 2017-04-19 | 2019-11-05 | 电子科技大学 | 基于chunk块版本号的分布式块存储***数据恢复判定方法 |
| US10296821B2 (en) * | 2017-08-17 | 2019-05-21 | Assa Abloy Ab | RFID devices and methods of making the same |
| CN111008026B (zh) | 2018-10-08 | 2024-03-26 | 阿里巴巴集团控股有限公司 | 集群管理方法、装置及*** |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2170454C2 (ru) * | 1994-03-07 | 2001-07-10 | Интернэшнл Бизнес Машинз Корпорейшн | Система и способ эффективного использования кэш-памяти в распределенной файловой системе |
| US6643672B1 (en) * | 2000-07-31 | 2003-11-04 | Hewlett-Packard Development Company, Lp. | Method and apparatus for asynchronous file writes in a distributed file system |
| US7065618B1 (en) * | 2003-02-14 | 2006-06-20 | Google Inc. | Leasing scheme for data-modifying operations |
| RU2005130414A (ru) * | 2004-10-01 | 2007-04-10 | Майкрософт Корпорейшн (Us) | Система и способ для определения переключения при неоптимальности целевого объекта назад и приоритета целевого объекта для распределенной файловой системы |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5544347A (en) * | 1990-09-24 | 1996-08-06 | Emc Corporation | Data storage system controlled remote data mirroring with respectively maintained data indices |
| US6256642B1 (en) * | 1992-01-29 | 2001-07-03 | Microsoft Corporation | Method and system for file system management using a flash-erasable, programmable, read-only memory |
| US5634096A (en) * | 1994-10-31 | 1997-05-27 | International Business Machines Corporation | Using virtual disks for disk system checkpointing |
| US5933847A (en) * | 1995-09-28 | 1999-08-03 | Canon Kabushiki Kaisha | Selecting erase method based on type of power supply for flash EEPROM |
| US6052797A (en) * | 1996-05-28 | 2000-04-18 | Emc Corporation | Remotely mirrored data storage system with a count indicative of data consistency |
| US6460054B1 (en) * | 1999-12-16 | 2002-10-01 | Adaptec, Inc. | System and method for data storage archive bit update after snapshot backup |
| US7194504B2 (en) * | 2000-02-18 | 2007-03-20 | Avamar Technologies, Inc. | System and method for representing and maintaining redundant data sets utilizing DNA transmission and transcription techniques |
| JP4473513B2 (ja) * | 2003-02-27 | 2010-06-02 | 富士通株式会社 | 原本性検証装置および原本性検証プログラム |
| US7624021B2 (en) * | 2004-07-02 | 2009-11-24 | Apple Inc. | Universal container for audio data |
| US7716180B2 (en) * | 2005-12-29 | 2010-05-11 | Amazon Technologies, Inc. | Distributed storage system with web services client interface |
| US7778972B1 (en) * | 2005-12-29 | 2010-08-17 | Amazon Technologies, Inc. | Dynamic object replication within a distributed storage system |
| CN100437502C (zh) * | 2005-12-30 | 2008-11-26 | 联想(北京)有限公司 | 基于安全芯片的防病毒方法 |
| CN1859204A (zh) * | 2006-03-21 | 2006-11-08 | 华为技术有限公司 | 实现双机热备份中同步数据的方法及装置 |
| KR20090102789A (ko) * | 2006-12-06 | 2009-09-30 | 퓨전 멀티시스템즈, 인크.(디비에이 퓨전-아이오) | 프로그레시브 ｒａｉｄ를 이용한 데이터 저장 장치, 시스템 및 방법 |
| CN100445963C (zh) * | 2007-02-15 | 2008-12-24 | 华为技术有限公司 | 一种实现高可靠性空闲链表的方法及装置 |
| JP4897524B2 (ja) * | 2007-03-15 | 2012-03-14 | 株式会社日立製作所 | ストレージシステム及びストレージシステムのライト性能低下防止方法 |
| US7975109B2 (en) * | 2007-05-30 | 2011-07-05 | Schooner Information Technology, Inc. | System including a fine-grained memory and a less-fine-grained memory |
| CN101334797B (zh) | 2008-08-04 | 2010-06-02 | 中兴通讯股份有限公司 | 一种分布式文件***及其数据块一致性管理的方法 |
-
2008
- 2008-08-04 CN CN2008101422912A patent/CN101334797B/zh active Active
-
2009
- 2009-07-30 WO PCT/CN2009/000855 patent/WO2010015143A1/zh active Application Filing
- 2009-07-30 RU RU2011107514/08A patent/RU2449358C1/ru active
- 2009-07-30 EP EP09804443A patent/EP2330519A4/en not_active Withdrawn
- 2009-07-30 US US13/057,187 patent/US8285689B2/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2170454C2 (ru) * | 1994-03-07 | 2001-07-10 | Интернэшнл Бизнес Машинз Корпорейшн | Система и способ эффективного использования кэш-памяти в распределенной файловой системе |
| US6643672B1 (en) * | 2000-07-31 | 2003-11-04 | Hewlett-Packard Development Company, Lp. | Method and apparatus for asynchronous file writes in a distributed file system |
| US7065618B1 (en) * | 2003-02-14 | 2006-06-20 | Google Inc. | Leasing scheme for data-modifying operations |
| RU2005130414A (ru) * | 2004-10-01 | 2007-04-10 | Майкрософт Корпорейшн (Us) | Система и способ для определения переключения при неоптимальности целевого объекта назад и приоритета целевого объекта для распределенной файловой системы |
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2653278C2 (ru) * | 2012-08-03 | 2018-05-07 | ЗэтТиИ Корпорейшн | Способ и устройство хранения для распределенной файловой системы |
| RU2686594C2 (ru) * | 2014-05-11 | 2019-04-29 | МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи | Файловая служба, использующая интерфейс совместного файлового доступа и передачи состояния представления |
| US10536523B2 (en) | 2014-05-11 | 2020-01-14 | Microsoft Technology Licensing, Llc | File service using a shared file access-rest interface |
| US11797502B2 (en) | 2015-08-28 | 2023-10-24 | Hedera Hashgraph, Llc | Methods and apparatus for a distributed database within a network |
| US11232081B2 (en) | 2015-08-28 | 2022-01-25 | Swirlds, Inc. | Methods and apparatus for a distributed database within a network |
| US11734260B2 (en) | 2015-08-28 | 2023-08-22 | Hedera Hashgraph, Llc | Methods and apparatus for a distributed database within a network |
| US11677550B2 (en) | 2016-11-10 | 2023-06-13 | Hedera Hashgraph, Llc | Methods and apparatus for a distributed database including anonymous entries |
| US11657036B2 (en) | 2016-12-19 | 2023-05-23 | Hedera Hashgraph, Llc | Methods and apparatus for a distributed database that enables deletion of events |
| RU2754189C2 (ru) * | 2016-12-19 | 2021-08-30 | Свирлдз, Инк. | Способы и устройство для распределенной базы данных, которая позволяет удалять события |
| RU2776826C2 (ru) * | 2016-12-19 | 2022-07-27 | Свирлдз, Инк. | Способы и устройство для распределенной базы данных, которая позволяет удалять события |
| US11256823B2 (en) | 2017-07-11 | 2022-02-22 | Swirlds, Inc. | Methods and apparatus for efficiently implementing a distributed database within a network |
| US11681821B2 (en) | 2017-07-11 | 2023-06-20 | Hedera Hashgraph, Llc | Methods and apparatus for efficiently implementing a distributed database within a network |
| US11537593B2 (en) | 2017-11-01 | 2022-12-27 | Hedera Hashgraph, Llc | Methods and apparatus for efficiently implementing a fast-copyable database |
| RU2696212C1 (ru) * | 2018-01-30 | 2019-07-31 | Леонид Евгеньевич Посадсков | Способ обеспечения защищенной передачи данных в облачных хранилищах с использованием частичных образов |
| US11475150B2 (en) | 2019-05-22 | 2022-10-18 | Hedera Hashgraph, Llc | Methods and apparatus for implementing state proofs and ledger identifiers in a distributed database |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2010015143A1 (zh) | 2010-02-11 |
| EP2330519A1 (en) | 2011-06-08 |
| EP2330519A4 (en) | 2011-11-23 |
| CN101334797B (zh) | 2010-06-02 |
| US8285689B2 (en) | 2012-10-09 |
| CN101334797A (zh) | 2008-12-31 |
| US20110161302A1 (en) | 2011-06-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2449358C1 (ru) | Распределенная файловая система и способ управления согласованностью блоков данных в такой системе | |
| US10467246B2 (en) | Content-based replication of data in scale out system | |
| JP5254611B2 (ja) | 固定内容分散データ記憶のためのメタデータ管理 | |
| US9703803B2 (en) | Replica identification and collision avoidance in file system replication | |
| WO2017049764A1 (zh) | 数据读写方法及分布式存储*** | |
| US7778984B2 (en) | System and method for a distributed object store | |
| JP5918243B2 (ja) | 分散型データベースにおいてインテグリティを管理するためのシステム及び方法 | |
| US7590672B2 (en) | Identification of fixed content objects in a distributed fixed content storage system | |
| US8229897B2 (en) | Restoring a file to its proper storage tier in an information lifecycle management environment | |
| US8566555B2 (en) | Data insertion system, data control device, storage device, data insertion method, data control method, data storing method | |
| US10860738B2 (en) | Augmented metadata and signatures for objects in object stores | |
| US7155464B2 (en) | Recovering and checking large file systems in an object-based data storage system | |
| US7689764B1 (en) | Network routing of data based on content thereof | |
| US20030187883A1 (en) | Internally consistent file system image in distributed object-based data storage | |
| JP2013544386A5 (ru) | ||
| US9218251B1 (en) | Method to perform disaster recovery using block data movement | |
| CN110163009B (zh) | Hdfs存储平台的安全校验及修复的方法和装置 | |
| CN115277145B (zh) | 分布式存储访问授权管理方法、***、设备和可读介质 | |
| US11669546B2 (en) | Synchronizing replicated data in a storage network | |
| CN114416665B (zh) | 一种数据一致性检测和修复的方法、装置及介质 | |
| CN115470041A (zh) | 一种数据灾备管理方法及装置 | |
| US11237921B2 (en) | Protecting storage backup configuration | |
| CN111400098A (zh) | 一种副本管理方法、装置、电子设备及存储介质 | |
| WO2011046551A1 (en) | Content storage management | |
| KR101323729B1 (ko) | 비대칭 클러스터링 파일 시스템에서의 오류 복구 처리 장치 및 방법 |