Friday May 29, 2015

On Self Describing Filesystem Metadata, by Darrick Wong

The following is a write-up by Oracle mainline Linux kernel engineer, Darrick Wong, providing some backround on his work on Linux FS Metadata Checksumming, which, after many years of work, will will be turned on by default in the upcoming e2fsprogs 1.43 and xfsprogs 3.2.3.

One of the bigger problems facing filesystems today is the problem of online verification of the integrity of the metadata. Even though storage bandwidth has increased considerably and (in some cases) seek times have dropped to nearly zero, the forensic work required to square a filesystem back to sense increases at least as quickly as metadata size, which scales up about as quickly as total storage capacity. Furthermore, the threat of random bit corruption in a critical piece of metadata causing unrecoverable filesystem damage remains as true as it ever was -- the author has encountered scenarios where corruption in the block usage data structure results in the block allocator crosslinking file data with metadata, which multiplies the resulting damage.

Self-describing metadata helps both the kernel and the repair tools to decide if a block actually contains the data the filesystem is trying to read. In most cases, this involves tagging each metadata block with a tuple describing the type of the block, the block number where the block lives, a unique identifier tying the block to the filesystem (typically the FS UUID), the checksum of the data in the block, and some sort of pointer to the metadata object that points to the block (the owner). For a transactional filesystem, it is useful also to record the transaction ID to facilitate analyzing where in time a corruption happened. Storing the FS UUID is useful in deciding whether an arbitrary metadata block actually belongs to this filesystem, or if it belongs to something else -- a previous filesystem or perhaps an FS image stored inside the filesystem. Given a theoretical mental model of an FS as a forest of trees all reachable by a single root, owner pointers theoretically enable a repair effort to reconstruct missing parts of the tree.

The checksum, while neither fool-proof nor tamper-proof, is usually a fast method to detect random bit corruption. While it is possible to choose stronger schemes such as sha256 (or even cryptographically signed hashes), these come with high performance and management overhead, which is why most systems choose a checksum of some sort. Both filesystems chose CRC32c, primarily for its ability to detect bit flips and the presence of hardware acceleration on a number of platforms. One area that the neither XFS nor ext4 have touched on is the topic of data checksumming. While it is technically possible to record the same self-description tuple for data blocks (btrfs stores at least the checksum), this was deliberately left out of the design for both XFS and ext4. There will be more to say about data block back-references later. First, requiring a metadata update (and log transaction) for every write of every block will have a sharply negative impact on rewrite performance. Second, some applications ensure that their internal file formats already provide the integrity data that the application requires; for them, the filesystem overhead is unnecessary. Migration of the data and its integrity information is easier when both are encapsulated in a single file. Third, performing file data integrity in userspace has the advantage that the integrity profiles can be customised for each program -- some may deem bitflip detection via CRC to be sufficient; others might want sha256 to take advantage of the reduced probability of collisions; and still more might go all the way to verification through digital signatures. There does not seem to be a pressing need to provide data block integrity specifically through the filesystem, unlike metadata, which is accessible only through the filesystem. In XFS, self-describing metadata was introduced with a new (v5) on-disk format. All existing v4 structure were enlarged to store (type, blocknr, fsuuid, owner, lsn); this allowed XFS to deploy a set of block verifiers to decide quickly if a block being read in matches what the reader expects. These verifiers also perform a quick check of the block's metadata at read and write time to detect bad metadata resulting from coding bugs. Unfortunately, it is necessary to reformat the filesystem to accomodate the resized metadata headers. The kernel and the repair tool, however, are still quick to discard broken metadata; however, as we will see, this new metadata format extension opens the door to enhanced recovery efforts.

For ext4, it was discovered that every metadata structure had sufficient room to squeeze in an extra four or two byte field to store checksum data while leaving the structure size and layout otherwise intact. This meant making a few compromises in the design -- instead of adding the 5 attributes to each block, a single 32-bit checksum is calculated over the type, blocknr, fsuuid, owner and block data; this value is then plugged into the checksum field. This scheme allows ext4 to decide if a block's contents match what we thought we were reading, but it will not enable us to reconstruct missing parts of the FS metadata object hierarchy. However, existing ext2/3/4 filesystems can be upgraded easily via tune2fs. In the near future, XFS could grow a few new features to enable an even greater level of self-directed integrity checking and repair. Inodes may soon grow parent directory pointers, which enable XFS to reconstruct directories by scanning all non-free (link count > 0) inodes in the filesystem. Similarly, a proposed block reverse-mapping btree makes it possible for XFS to rebuild a file by iterating all the rmaps looking for extent data. These two operations can even be performed online, which means that the filesystem can evolve towards self-healing abilities. Major factors blocking this development are (a) the inability to close an open file and (b) the need to shut down the allocators while we repair per-AG data. These improvements will be harder or impossible to implement for ext4, unfortunately.

The metadata checksumming features as described will be enabled by default in the respective mkfs tools as part of the next releases of e2fsprogs (1.43) and xfsprogs (3.2.3). Existing filesystems must be upgraded (ext4) or reformatted and reloaded (xfs) manually.

-- D

Further reading:

Tuesday Apr 01, 2014

LSF/MM 2014 and ext4 Summit Notes by Darrick Wong

This is a contributed post from Darrick Wong, storage engineer on the Oracle mainline Linux kernel team.

The following are my notes from LSF/MM 2014 and the ext4 summit, held last week in Napa Valley, CA.

  • Discussed the draft DIX passthrough interface. Based on Zach Brown's suggestions last week, I rolled out a version of the patch with a statically defined io extensions struct, and Martin Petersen said he'd try porting some existing asmlib clients to use the new interface, with a few field-enlarging tweaks. For the most part nobody objected; Al Viro said he had no problems "yet" -- but I couldn't tell if he had no idea what I was talking about, or if he was on board with the API. It was also suggested that I seek the opinion of Michael Kerrisk (the manpages maintainer) about the API. As for the actual implementation, there are plenty of holes in it that I intend to fix this week. The NFS/CIFS developers I spoke to were generally happy to hear that the storage side was finally starting to happen, and that they could get to working on the net-fs side of things now. Nicholas Bellinger noted that targetcli can create DIF disks even with the fileio backend, so he suggested I play with that over scsi_debug.

  • A large part of LSF was taken up with the discussion of how to handle the brave new world of weird storage devices. To recap: in the beginning, software had to deal with the mechanical aspects of a rotating disk; addressing had to be done in terms of cylinders, heads, and sectors (CHS). This made it difficult to innovate drive mechanics, as it was impossible to express things like variable zone density to existing software. SCSI eliminated this pain by abstracting a disk into a big tub of consecutive sectors, which simplified software quite a bit, though at some cost to performance. But most programs weren't trying to wring the last iota of performance out of disks and didn't care. So long as some attention was paid to data locality, disks performed adequately. Fast forward to 2014: now we have several different storage device classes: Flash, which has no seek penalty but prefers large writeouts; SMR drives with hard-disk seek penalties but requirements that all writes within a ~256MB zone be written in linear order; RAIDs, which by virtue of stripe geometries violate a few of the classic hard disk thinking; and NVMe devices which implement atomic read and write operations. Dave Chinner suggests that rather than retrofitting each filesystem to deal with each of these devices, it might be worth shoving all the block allocation and mapping operation down to a device mapper (dm) shim layer that can abstract away different types of storage, leaving FSes to manage namespace information. This suggestion is very attractive on a few levels: Benefits include the ability to emulate atomic read/writes with journalling, more flexible software-defined FTLs for flash and SMR, and improved communication with cloud storage systems -- Mike Snitzer had a session about dm-thinp and the proper way for FSes to communicate allocation hints to the underlying storage; this would certainly seem to fit the bill. I mentioned that Oracle's plans for cheap ext4 reflink would be trivial to implement with dm shims. Unfortunately, the devil is in the details -- when will we see code? For that reason, Ted Ts'o was openly skeptical.

  • The postgresql developers showed up to complain about stable pages and to ask for a less heavyweight fsync() -- currently, when fsync is called, it assumes that the caller wants all dirty data written out NOW, so it writes dirty pages with WRITE_SYNC, which starves reads. For postgresql this is suboptimal since fsync is typically called by the checkpointing code, which doesn't need to be fast and doesn't care if fsync writeback is not fast. There was an interlock scheduled for Thursday afternoon, but I was unable to attend. See LWN for more detailed coverage of the postgresql (and FB) sessions.

  • At the ext4 summit, we discussed a few cleanups, such as removing the use of buffer_heads and the impending removal of the ext2/3 drivers. Removing buffer_heads in the data path has the potential benefit that it'll make the transition to supporting block/sector size > page size easier, as well as reducing memory requirements (buffer heads are a heavyweight structure now). There was also the feeling that once most enterprise distros move to ext4, it will be a lot easier to remove ext3 upstream because there will be a lot more testing of the use of ext4.ko to handle ext2/3 filesystems. There was a discussion of removing ext2 as well, though that stalled on concerns that Christoph Hellwig (hch) would like to see ext2 remain as a "sample" filesystem, though Jan Kara could be heard muttering that nobody wants a bitrotten example.

  • The other major new ext4 feature discussed at the ext4 summit is per-data block metadata. This got started when Lukas Czerner (lukas) proposed adding data block checksums to the filesystem. I quickly chimed in that for e2fsck it would be helpful to have per-block back references to ease reconstruction of the filesystem, at which point the group started thinking that rather than a huge static array of block data, the complexity of a b-tree with variable key size might well be worth the effort. Then again, with all the proposed filesystem/block layer changes, Ted said that he might be open to a quick v1 implementation because the block shim layer discussed in the SMR forum could very well obviate the need for a lot of ext4 features. Time will tell; Ted and I were not terribly optimistic that any of that software is coming soon. In any case, lukas went home to refine his proposal. The biggest problem is ext4's current lack of a btree implementation; this would have to be written or borrowed, and then tested. I mentioned to him that this could be the cornerstone of reimplementing a lot of ext4 features with btrees instead of static arrays, which could be a good thing if RH is willing to spend a lot of engineering time on ext4.

  • Michael Halcrow, speaking at the ext4 summit, discussed implementing a lightweight encrypted filesystem subtree feature. This sounds a lot like ecryptfs, but hopefully less troublesome than the weird shim fs that is ecryptfs. For the most part he seemed to need (a) the ability to inject his code into the read/write path and some ability to store a small amount of per-inode encryption data. His use-case is Chrome OS, which apparently needs the ability for cache management programs to erase parts of a(nother) user's cache files without having the ability to access the file. The discussion concluded that it wouldn't be too difficult for him to start an initial implementation with ext4, but that much of this ought to be in the VFS layer.

 -- Darrick

[Ed: see also the LWN coverage of LSF/MM]

Wednesday May 08, 2013

Ext4 filesystem workshop report by Mingming Cao

This is a contributed post from Mingming Cao, lead ext4 developer for the Oracle mainline Linux kernel team.

I attended the second ext4 workshop hosted at the third day of Linux Collaboration Summit 2013.  Participants included Google, RedHat, SuSE, Taobao, and Lustre. We had about 2-4 hours of good discussion about the roadmap of ext4 for next year.

Ext4 write stall issue

A write Stall issue was reported by MM folks found during page claim testing over ext4. There is lock contention in JBD2 between journal commit and new transaction, resulting blocking IOs waiting for locks. More precisely it is caused by do_get_write_access() will block at lock_buffer(). The problem is nothing new should be visible in ext3 too. But new kernel becomes more visitable. Ted has proposed two fixes 1) avoid calling lock_buffer() during do_get_write_acess() 2) adjust jbd2 to manage buffer_head itself to reduce latency. Fixing in JBD2 would be a big effort. Propose 1) sounds more reasonable to work with.  The first action is to mark metadata update with RED_* to avoid the priority disorder meanwhile looking at the block IO layer and see if there is a way to move blocking IOs to a separate queue.

DIO lock contention issue

Another topic brought up is the Direct IO locking contention issue.  On DIO read side there is already no lock hold, but only for pagesize=blocksize case. There is not a fundamental issue why the no lock for direct IO read is not possible for blocksize <Pagesize -- agree we should remove this limit. On the Direct IO write side, two proposals about concurrent direct IO writes. One is based on in memory extent status tree, similar to xfs does, which allows dio write to different range of file possible. Another proposal is the general VFS solution which lock the pages in range during direct IO write. This would benefit all filesystems, but has challenge of sorting out multiple locks orders.  Jan Kara had a LSF session for this in more details. Looks like this approach is more promising.

Extent tree disk layout

There is discussion about support true 64 bit ext4 filesystem (64bit inode number and 64 bit block number -- currently 32 bit inode number and 48 bit blocknumber) in order to scales well. The ext4 on disk extent structure could be extended to support larger file, such as 64-bits physical block, bigger logical block, and using cluster-size as unit in extent.  This is easy to handle in e2fsprogs, but change on disk extent tree format is quite tricky to play well with punch hole, truncate etc., which depends on extent tree format. One solution is to add an layer of extent tree abstraction in memory, but this considered a big effort.

This was not entirely impossible.Jan Kara is working on extent tree code clean up, trying to factor out some common code first and teach the block allocation related code doesn't have to reply on on disk extent format. This is not a high priority for now.

Fallocate performance issue

A performance problem has been reported with fallocate really large file. Ext4 multile block allocator code(mballoc) currently limits how large a chunk of blocks could be allocated at a time. Should able to hack mballoc at lest 16MB at a time, instead of 2MB a time.

This brought out another related mballoc limitation. At present the mballoc normalize the request size to the nearest power of 2, up to 1MB.  The original requirement for this is for raid alignment.  If we lift up this limitation, with non normalized request size, fallocate could be 3 times faster.  Most likely we will address this quickly.

Buddy bitmap flush from mem too quickly

Under some memory pressure test, the buddy bitmap used to guide ext4 block allocation was been pushed out from memory too quickly, even though mark page dirty doesn't strong enough -- talk to mm people about interface mark page access() interface alternate, which ended with agreement to use fadvise to mark the pages as metadata.

data=guarded journaling mode

Back to ext3 time when there is no delayed allocation, the fsync() performance is badly hurt by the data=ordered mode, which forces flush out the data first (might be entire filesystem dirty data) before commit a metadata update. There is proposal of data=guarded mode which protect data inconsistency issue upon power failure, but would result in much better fsync result. The basic idea is the isize update wont be updated until the data has flushed to disk. This would drop of difference between data=writeback mode and data=ordered mode.

At the meeting this journalling mode was brought up again to see if we need this for ext4. Given ext4 implemented delayed allocation, the fsync performance was much improved (no need to flush unrelated file data), due to the benefit of delayed allocation, so performance benefit is not so obvious. But the benefit of this new journalling mode would great help 1) unwritten extent conversion issue, so that we could have full dio read no lock implementation, 2) also get ride of extra journalling mode.

ext4 filesystem mount options

There is discussion of ext4 testing cost due to many many different combination of ext4 mount options (total 70). Part of the reason is distro is trying to just maintain ext4 filesystem for all three filesystem (ext2.3.4) there is effort to test and valid the ext4 module still work as expected when mounted as ext3 with different mount options.  A few important mount options which need special care/investigate including support for indirect-based/extent-based files; support for Asynchronous journal commit; data=journal and delayed allocation exclusive issue.

So short summary of next year ext4 development is to mostly focus on reduce latency, improve performance and code reorganization.

-- Mingming Cao


The Oracle mainline Linux kernel team works as part of the Linux kernel community to develop new features and maintain existing code.

Our team is globally distributed and includes leading core kernel developers and industry veterans.

This blog is edited by James Morris <>


« July 2016