Browse Prior Art Database

Method for ensuring reliability semantics in file system environment

IP.com Disclosure Number: IPCOM000234103D
Publication Date: 2014-Jan-13
Document File: 5 page(s) / 141K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to make a file system aware of the reliability level of the storage pool in an erasure code environment. In addition to using existing mechanisms, the Maximum Reliability (MAX_REL) supported by the file system is based on the reliability level of the storage pool.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 32% of the total text.

Page 01 of 5

Method for ensuring reliability semantics in file system environment

File System functionality can be divided into two components: user component and storage component. The user component is responsible for managing files within directories, file path traversals, and user access to the file. The storage component of the file system determines how a file is stored physically on the storage device.

The problem addressed herein is illustrated in Figure 1. The file system is configured such that each application block is split into four data blocks and has three associated parity blocks. These blocks, A1 to A7, are stored on seven different disks from Disk1 to Disk7. The configuration has three parity disks for each erasure encoding which, from the user's perspective, is expected to sustain three disk failures. The storage pool controller has an internal disk, which stores a block mapping table. This table is also replicated on disk8 for additional reliability.

The failure of the storage pool controller's internal disk and replica disk8 (storing replica) results in the loss of a block mapping table. With this metadata loss, information about where each vblock is stored is lost, making all data block orphans and causing indirect loss of data. This breaks the semantics of the erasure code.

Figure 1: Configuration for file system storage and block mapping; illustration of the problem

1


Page 02 of 5

The problem is that the file system is unaware of the reliability level of the block mapping table; the table might promise a higher level of reliability per the Service Level Agreement (SLA). This is in the form of the number of disk failures it can sustain. Failure in mapping table storage and its replica causes an indirect loss of data. This results in a breach of the SLA.

Based on number of disks in the array controller and the reliability presented in the customer SLA, the file system decides the erasure code level required for the storage of given application block. This determines how many additional parity blocks need to be added for a given application block, so that it can sustain a given number of failures. Currently, file system promises reliability guarantee based on the number of parity blocks it is managing.

However, this logic does not consider how many failures a block mapping table can survive. It does not consider the number of replicas a block mapping table can have or the number of internal disk failures with controller or external disk failures this table can sustain without loss of data. Thus, even if a file system promises a certain guarantee and is maintaining reliability at its level, these semantics can be broken if the same reliability is not guaranteed by the storage controller for storing the block mapping table.

The solution is a method to make a file system aware of the reliability level of the storage pool in an erasure code environment. The Maximum Reliability (MAX_REL) supported by the file system is based o...