|This article brought to you by LWN subscribers|
Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.
By Jonathan Corbet
August 31, 2009
The conversation actually began last March, when Pavel Machek posted a proposed documentation patch describing the assumptions that he saw as underlying the design of Linux filesystems. Things went quiet for a while, before springing back to life at the end of August. It would appear that Pavel had run into some data-loss problems when using a flash drive with a flaky connection to the computer; subsequent tests done by deliberately removing active drives confirmed that it is easy to lose data that way. He hadn't expected that:
Before I pulled that flash card, I assumed that doing so is safe, because flashcard is presented as block device and ext3 should cope with sudden disk disconnects. And I was wrong wrong wrong. (Noone told me at the university. I guess I should want my money back).
In an attempt to prevent a surge in refund requests at universities worldwide, Pavel tried to get some warnings put into the kernel documentation. He has run into a surprising amount of opposition, which he (and some others) have taken as an attempt to sweep shortcomings in Linux filesystems under the rug. The real story, naturally, is a bit more complex.
Journaling technology like that used in ext3 works by writing some data to the filesystem twice. Whenever the filesystem must make a metadata change, it will first gather together all of the block-level changes required and write them to a special area of the disk (the journal). Once it is known that the full description of the changes has made it to the media, a "commit record" is written, indicating that the filesystem code is committed to the change. Once the commit record is also safely on the media, the filesystem can start writing the metadata changes to the filesystem itself. Should the operation be interrupted (by a power failure, say, or a system crash or abrupt removal of the media), the filesystem can recover the plan for the changes from the journal and start the process over again. The end result is to make metadata changes transactional; they either happen completely or not at all. And that should prevent corruption of the filesystem structure.
One thing worth noting here is that actual data is not normally written to the journal, so a certain amount of recently-written data can be lost in an abrupt failure. It is possible to configure ext3 (and ext4) to write data to the journal as well, but, since the performance cost is significant, this option is not heavily used. So one should keep in mind that most filesystem journaling is there to protect metadata, not the data itself. Journaling does provide some data protection anyway - if the metadata is lost, the associated data can no longer be found - but that's not its primary reason for existing.
It is not the lack of journaling for data which has created grief for Pavel and others, though. The nature of flash-based storage makes another "interesting" failure mode possible. Filesystems work with fixed-size blocks, normally 4096 bytes on Linux. Storage devices also use fixed-size blocks; on traditional rotating media, those blocks are traditionally 512 bytes in length, though larger block sizes are on the horizon. The key point is that, on a normal rotating disk, the filesystem can write a block without disturbing any unrelated blocks on the drive.
Flash storage also uses fixed-size blocks, but they tend to be large - typically tens to hundreds of kilobytes. Flash blocks can only be rewritten as a unit, so writing a 4096-byte "block" at the operating system level will require a larger read-modify-write cycle within the flash drive. It is certainly possible for a careful programmer to write flash-drive firmware which does this operation in a safe, transactional manner. It is also possible that the flash drive manufacturer was rather more interested in getting a cheap device to market quickly than careful programming. In the commodity PC hardware market, that possibility becomes something much closer to a certainty.
What this all means is that, on a low-quality flash drive, an interrupted write operation could result in the corruption of blocks unrelated to that operation. If the interrupted write was for metadata, a journaling filesystem will redo the operation on the next mount, ensuring that the metadata ends up in its intended destination. But the filesystem cannot know about any unrelated blocks which might have been trashed at the same time. So journaling will not protect against this kind of failure - even if it causes the sort of metadata corruption that journaling is intended to prevent.
This is the "bug" in ext3 that Pavel wished to document. He further asserted that journaling filesystems can actually make things worse in this situation. Since a full fsck is not normally required on journaling filesystems, even after an improper dismount, any "collateral" metadata damage will go undetected. At best, the user may remain unaware for some time that random data has been lost. At worst, corrupt metadata could cause the code to corrupt other parts of the filesystem over the course of subsequent operation. The skipped fsck may have enabled the system to come back up quickly, but it has done so at the risk of letting corruption persist and, possibly, spread.
One could easily argue that the real problem here is the use of hidden translation layers to make a flash device look like a normal drive. David Woodhouse did exactly that:
This just goes to show why having this "translation layer" done in firmware on the device itself is a _bad_ idea. We're much better off when we have full access to the underlying flash and the OS can actually see what's going on. That way, we can actually debug, fix and recover from such problems.
The manufacturers of flash drives have, thus far, proved impervious to this line of reasoning, though.
There is a similar failure mode with RAID devices which was also discussed. Drives can be grouped into a RAID5 or RAID6 array, with the result that the array as a whole can survive the total failure of any drive within it. As long as only one drive fails at a time, users of RAID arrays can rest assured that the smoke coming out of their array is not taking their data with it.
But what if more than one drive fails? RAID works by combining blocks into larger stripes and associating checksums with those stripes. Updating a block requires rewriting the stripe containing it and the associated checksum block. So, if writing a block can cause the array to lose the entire stripe, we could see data loss much like that which can happen with a flash drive. As a normal rule, this kind of loss will not occur with a RAID array. But it can happen if (1) one drive has already failed, causing the array to run in "degraded" mode, and (2) a second failure occurs (Pavel pulls the power cord, say) while the write is happening.
Pavel concluded from this scenario that RAID devices may actually be more dangerous than storing data on a single disk; he started a whole separate subthread (under the subject "raid is dangerous but that's secret") to that effect. This claim caused a fair amount of concern on the list; many felt that it would push users to forgo technologies like RAID in favor of single, non-redundant drive configurations. Users who do that will avoid the possibility of data loss resulting from a specific, unlikely double failure, but at the cost of rendering themselves entirely vulnerable to a much more likely single failure. The end result would be a lot more data lost.
The real lessons from this discussion are fairly straightforward:
- Treat flash drives with care, do not expect them to be more reliable than they are, and do not remove them from the system until all writes are complete.
- RAID arrays can increase data reliability, but an array which is not running with its full complement of working, populated drives has lost the redundancy which provides that reliability. If the consequences of a second failure would be too severe, one should avoid writing to arrays running in degraded mode.
- As Ric Wheeler pointed out, the easiest way to lose data on a Linux system is to run the disks with their write cache enabled. This is especially true on RAID5/6 systems, where write barriers are still not properly supported. There has been some talk of disabling drive write caches and enabling barriers by default, but no patches have been posted yet.
- There is no substitute for good backups. Your editor would add that any backups which have not been checked recently have a strong chance of not being good backups.
How this information will be reflected in the kernel documentation remains to be seen. Some of it seems like the sort of system administration information which is not normally considered appropriate for inclusion in the documentation of the kernel itself. But there is value in knowing what assumptions one's filesystems are built on and what the possible failure modes are. A better understanding of how we can lose data can only help us to keep that from actually happening.
(Log in to post comments)
For the gene, see EXT3 (gene).
|Full name||Third extended file system|
|Introduced||November 2001 with Linux 2.4.15|
|Partition identifier||0x83 (MBR)|
|Directory contents||Table, hashed B-tree with dir_index enabled|
|File allocation||bitmap (free space), table (metadata)|
|Max. volume size||4 TiB – 32 TiB|
|Max. file size||16 GiB – 2 TiB|
|Max. number of files||Variable, allocated at creation time|
|Max. filename length||255 bytes|
|Allowed characters in filenames||All bytes except NUL ('\0') and '/'|
|Dates recorded||modification (mtime), attribute modification (ctime), access (atime)|
|Date range||December 14, 1901 – January 18, 2038|
|Date resolution||1 s|
|Attributes||allow-undelete, append-only, h-tree (directory), immutable, journal, no-atime, no-dump, secure-delete, synchronous-write, top (directory)|
|File system permissions||Unix permissions, ACLs and arbitrary security attributes (Linux 2.6 and later)|
|Transparent encryption||No (provided at the block device level)|
|Supported operating systems||Linux, BSD, ReactOS,Windows (through an IFS)|
ext3, or third extended filesystem, is a journaled file system that is commonly used by the Linux kernel. It is the default file system for many popular Linux distributions. Stephen Tweedie first revealed that he was working on extending ext2 in Journaling the Linux ext2fs Filesystem in a 1998 paper, and later in a February 1999 kernel mailing list posting. The filesystem was merged with the mainline Linux kernel in November 2001 from 2.4.15 onward. Its main advantage over ext2 is journaling, which improves reliability and eliminates the need to check the file system after an unclean shutdown. Its successor is ext4.
The performance (speed) of ext3 is less attractive than competing Linux filesystems, such as ext4, JFS, ReiserFS, and XFS, but ext3 has a significant advantage in that it allows in-place upgrades from ext2 without having to backup and restore data. Benchmarks suggest that ext3 also uses less CPU power than ReiserFS and XFS. It is also considered safer than the other Linux file systems, due to its relative simplicity and wider testing base.
ext3 adds the following features to ext2:
Without these features, any ext3 file system is also a valid ext2 file system. This situation has allowed well-tested and mature file system maintenance utilities for maintaining and repairing ext2 file systems to also be used with ext3 without major changes. The ext2 and ext3 file systems share the same standard set of utilities, e2fsprogs, which includes an fsck tool. The close relationship also makes conversion between the two file systems (both forward to ext3 and backward to ext2) straightforward.
ext3 lacks "modern" filesystem features, such as dynamic inode allocation and extents. This situation might sometimes be a disadvantage, but for recoverability, it is a significant advantage. The file system metadata is all in fixed, well-known locations, and data structures have some redundancy. In significant data corruption, ext2 or ext3 may be recoverable, while a tree-based file system may not.
The max number of blocks for ext3 is 232. The size of a block can vary, affecting the max number of files and the max size of the file system:
|1 KiB||16 GiB||4 TiB|
|2 KiB||256 GiB||8 TiB|
|4 KiB||2 TiB||16 TiB|
|8 KiB[limits 1]||2 TiB||32 TiB|
- ^In Linux, 8 KiB block size is only available on architectures which allow 8 KiB pages, such as Alpha.
There are three levels of journaling available in the Linux implementation of ext3:
- Journal (lowest risk)
- Both metadata and file contents are written to the journal before being committed to the main file system. Because the journal is relatively continuous on disk, this can improve performance, if the journal has enough space. In other cases, performance gets worse, because the data must be written twice—once to the journal, and once to the main part of the filesystem.
- Ordered (medium risk)
- Only metadata is journaled; file contents are not, but it's guaranteed that file contents are written to disk before associated metadata is marked as committed in the journal. This is the default on many Linux distributions. If there is a power outage or kernel panic while a file is being written or appended to, the journal will indicate that the new file or appended data has not been "committed", so it will be purged by the cleanup process. (Thus appends and new files have the same level of integrity protection as the "journaled" level.) However, files being overwritten can be corrupted because the original version of the file is not stored. Thus it's possible to end up with a file in an intermediate state between new and old, without enough information to restore either one or the other (the new data never made it to disk completely, and the old data is not stored anywhere). Even worse, the intermediate state might intersperse old and new data, because the order of the write is left up to the disk's hardware.
- Writeback (highest risk)
- Only metadata is journaled; file contents are not. The contents might be written before or after the journal is updated. As a result, files modified right before a crash can become corrupted. For example, a file being appended to may be marked in the journal as being larger than it actually is, causing garbage at the end. Older versions of files could also appear unexpectedly after a journal recovery. The lack of synchronization between data and journal is faster in many cases. JFS uses this level of journaling, but ensures that any "garbage" due to unwritten data is zeroed out on reboot. XFS also uses this form of journaling.
In all three modes, the internal structure of file system is assured to be consistent even after a crash. In any case, only the data content of files or directories which were being modified when the system crashed will be affected; the rest will be intact after recovery.
Because ext3 aims to be backward-compatible with the earlier ext2, many of the on-disk structures are similar to those of ext2. Consequently, ext3 lacks recent features, such as extents, dynamic allocation of inodes, and block sub-allocation. A directory can have at most 31998 subdirectories, because an inode can have at most 32,000 links (each direct subdirectory increases their parent folder inode link counter in the ".." reference).
ext3, like most current Linux filesystems, should not be fsck-ed while the filesystem is mounted for writing. Attempting to check a filesystem that is already mounted in read/write mode will (very likely) detect inconsistencies in the filesystem metadata. Where filesystem metadata is changing, and fsck applies changes in an attempt to bring the "inconsistent" metadata into a "consistent" state, the attempt to "fix" the inconsistencies will corrupt the filesystem.
There is no online ext3 defragmentation tool that works on the filesystem level. There is an offline ext2 defragmenter, , but it requires that the ext3 filesystem be converted back to ext2 first. However, may destroy data, depending on the feature bits turned on in the filesystem; it does not know how to handle many of the newer ext3 features.
There are userspace defragmentation tools, like Shake and defrag. Shake works by allocating space for the whole file as one operation, which will generally cause the allocator to find contiguous disk space. If there are files which are used at the same time, Shake will try to write them next to one another. Defrag works by copying each file over itself. However, this strategy works only if the file system has enough free space. A true defragmentation tool does not exist for ext3.
However, as the Linux System Administrator Guide states, "Modern Linux filesystem(s) keep fragmentation at a minimum by keeping all blocks in a file close together, even if they can't be stored in consecutive sectors. Some filesystems, like ext3, effectively allocate the free block that is nearest to other blocks in a file. Therefore it is not necessary to worry about fragmentation in a Linux system."
While ext3 is resistant to file fragmentation, ext3 can get fragmented over time or for specific usage patterns, like slowly writing large files. Consequently, ext4 (the successor to ext3) has an online filesystem defragmentation utility e4defrag and currently supports extents (contiguous file regions).
ext3 does not support the recovery of deleted files. The ext3 driver actively deletes files by wiping file inodes for crash safety reasons.
There are still several techniques and some free and proprietary software for recovery of deleted or lost files using file system journal analysis; however, they do not guarantee any specific file recovery.
e3compr is an unofficial patch for ext3 that does transparent compression. It is a direct port of e2compr and still needs further development. It compiles and boots well with upstream kernels, but journaling is not implemented yet.
Lack of snapshots support
Unlike a number of modern file systems, ext3 does not have native support for snapshots, the ability to quickly capture the state of the filesystem at arbitrary times. Instead, it relies on less-space-efficient, volume-level snapshots provided by the Linux LVM. The Next3 file system is a modified version of ext3 which offers snapshots support, yet retains compatibility with the ext3 on-disk format.
No checksumming in journal
ext3 does not do checksumming when writing to the journal. On a storage device with extra cache, if barrier=1 is not enabled as a mount option (in /etc/fstab), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash. This is because storage devices with write caches report to the system that the data has been completely written, even if it was written to the (volatile) cache.
If hard disk writes are done out-of-order (due to modern hard disks caching writes in order to amortize write speeds), it is likely that one will write a commit block of a transaction before the other relevant blocks are written. If a power failure or unrecoverable crash should occur before the other blocks get written, the system will have to be rebooted. Upon reboot, the file system will replay the log as normal, and replay the "winners" (transactions with a commit block, including the invalid transaction above, which happened to be tagged with a valid commit block). The unfinished disk write above will thus proceed, but using corrupt journal data. The file system will thus mistakenly overwrite normal data with corrupt data while replaying the journal. If checksums had been used, where the blocks of the "fake winner" transaction were tagged with a mutual checksum, the file system could have known better and not replayed the corrupt data onto the disk. Journal checksumming has been added to ext4.
Filesystems going through the device mapper interface (including software RAID and LVM implementations) may not support barriers, and will issue a warning if that mount option is used. There are also some disks that do not properly implement the write cache flushing extension necessary for barriers to work, which causes a similar warning. In these situations, where barriers are not supported or practical, reliable write ordering is possible by turning off the disk's write cache and using the data=journal mount option. Turning off the disk's write cache may be required even when barriers are available.
Applications like databases expect a call to fsync() to flush pending writes to disk, and the barrier implementation doesn't always clear the drive's write cache in response to that call. There is also a potential issue with the barrier implementation related to error handling during events, such as a drive failure. It is also known that sometimes some virtualization technologies do not properly forward fsync or flush commands to the underlying devices (files, volumes, disk) from a guest operating system. Similarly, some hard disks or controllers implement cache flushing incorrectly or not at all, but still advertise that it is supported, and do not return any error when it is used. There are so many ways to handle fsync and write cache handling incorrectly, it is safer to assume that cache flushing does not work unless it is explicitly tested, regardless of how reliable individual components are believed to be.
Near-time extinction due to date-stamp limitation
Ext3 stores dates as Unix time using four bytes in the file header. 32 bits does not give enough scope to continue processing files beyond January 18, 2038. This "Geek's Millenium" is expected to cause widespread disruption if not dealt with in a timely fashion.
Main article: ext4
On June 28, 2006, Theodore Ts'o, the principal developer of ext3, announced an enhanced version, called ext4. On October 11, 2008, the patches that mark ext4 as stable code were merged in the Linux 2.6.28 source code repositories, marking the end of the development phase and recommending its adoption. In 2008, Ts'o stated that although ext4 has improved features such as being much faster than ext3, it is not a major advance, it uses old technology, and is a stop-gap; Ts'o believes that Btrfs is the better direction, because "it offers improvements in scalability, reliability, and ease of management". Btrfs also has "a number of the same design ideas that reiser3/4 had".
- ^The maximum number of inodes (and hence the maximum number of files and directories) is set when the file system is created. If V is the volume size in bytes, then the default number of inodes is given by V/213 (or the number of blocks, whichever is less), and the minimum by V/223. The default was deemed sufficient for most applications. The max number of subdirectories in one directory is fixed to 32000.
- ^"ReactOS 0.4.2 Released". reactos.org. Retrieved 17 August 2016.
- ^Stephen C. Tweedie (May 1998). "Journaling the Linux ext2fs Filesystem"(PDF). Proceedings of the 4th Annual LinuxExpo, Durham, NC. Retrieved 2007-06-23.
- ^Stephen C. Tweedie (February 17, 1999). "Re: fsync on large files". Linux kernel mailing list.
- ^Rob Radez (November 23, 2001). "2.4.15-final". Linux kernel mailing list.
- ^ abhttps://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-ext4.html
- ^Piszcz, Justin. "Benchmarking Filesystems Part II". Linux Gazette (122).
- ^Ivers, Hans. "Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch".
- ^Smith, Roderick W. (2003-10-09). "Introduction to Linux filesystems and files". Linux.com. Archived from the original on August 30, 2011.
- ^Trageser, James (2010-04-23). "Which Linux filesystem to choose for your PC? Ext2, Ext3, Ext4, ReiserFS (Reiser3), Reiser4, XFS, Btrfs".
- ^Cao, Mingming. "Directory indexing". Features found in Linux 2.6.
- ^Matthew Wilcox. "Documentation/filesystems/ext2.txt". Linux kernel source documentation.
- ^ abDaniel Robbins (2001-12-01). "Common threads: Advanced filesystem implementor's guide, Part 8". IBM developerWorks. Archived from the original on 2007-10-13.
- ^curious onloooker: Speeding up ext3 filesystems. Evuraan.blogspot.com (2007-01-09). Retrieved on 2013-06-22.
- ^Radez, Rob (2005). "Extents, Delayed Allocation". future of ext3.
- ^Robert Nichols (2007-04-03) Re: How many sub-directories ? linux.derkeiler.com
- ^Andreas Dilger. "Post to the ext3-users mailing list". ext3-users mailing list post.
- ^Shake. Vleu.net. Retrieved on 2013-06-22.
- ^Defrag written in shell. Ck.kolivas.org (2012-08-19). Retrieved on 2013-06-22.
- ^Defrag written in Python. Bazaar.launchpad.net. Retrieved on 2013-06-22.
- ^RE: searching for ext3 defrag/file move program. Redhat.com (2005-03-04). Retrieved on 2013-06-22.
- ^5.10. Filesystems. Tldp.org (2002-11-09). Retrieved on 2013-06-22.
- ^"#849 closed Enhancement (fixed) - preallocation to prevent fragmentation". trac.transmissionbt.com.
- ^Oliver Diedrich (27 October 2008). "Tuning the Linux file system Ext3".
- ^Ext4 – Linux Kernel Newbies. Kernelnewbies.org (2011-05-19). Retrieved on 2013-06-22.
- ^Linux ext3 FAQ. Batleth.sapienti-sat.org. Retrieved on 2013-06-22.
- ^HOWTO recover deleted files on an ext3 file systemArchived 2010-09-19 at the Wayback Machine.. Xs4all.nl (2008-02-07). Retrieved on 2013-06-22.
- ^PhotoRec – GPL'd File Recovery. Cgsecurity.org. Retrieved on 2013-06-22.
- ^UFS Explorer Standard Recovery version 4. Ufsexplorer.com. Retrieved on 2013-06-22.
- ^e3compr – ext3 compression. Sourceforge.net. Retrieved on 2013-06-22.
- ^Jonathan Corbet. "The Next3 filesystem". LWN.
- ^ abRe: Frequent metadata corruption with ext3 + hard power-off. Archives.free.net.ph. Retrieved on 2013-06-22.
- ^Re: Frequent metadata corruption with ext3 + hard power-off. Archives.free.net.ph. Retrieved on 2013-06-22.
- ^Red Hat Enterprise Linux, Chapter 20. Write Barriers
- ^ext4: Add the journal checksum feature. Article.gmane.org (2008-02-26). Retrieved on 2013-06-22.
- ^Re: write barrier over device mapper supported or not?. Oss.sgi.com. Retrieved on 2013-06-22.
- ^XFS and zeroed files. Madduck.net (2008-07-11). Retrieved on 2013-06-22.
- ^Barrier Sync. forums.opensuse.org (March 2007)
- ^Re: Proposal for "proper" durable fsync() and fdatasync(). Mail-archive.com (2008-02-26). Retrieved on 2013-06-22.
- ^I/O Barriers, as of kernel version 2.6.31. Mjmwired.net. Retrieved on 2013-06-22.
- ^Virtualization and IO Modes = Extra Complexity. Mysqlperformanceblog.com (2011-03-21). Retrieved on 2013-06-22.
- ^SSD, XFS, LVM, fsync, write cache, barrier and lost transactions. Mysqlperformanceblog.com (2009-03-02). Retrieved on 2013-06-22.
- ^"Theodore Ts'o": Proposal and plan for ext2/3 future development work. LKML. Retrieved on 2013-06-22.
- ^Ryan Paul (2009-04-13). "Panelists ponder the kernel at Linux Collaboration Summit". Ars Technica. Retrieved 2009-08-22.
- ^Theodore Ts'o (2008-08-01). "Re: reiser4 for 2.6.27-rc1". linux-kernel (Mailing list). Retrieved 2010-12-31.
- "Linux ext3 FAQ". as of 2004-10-14.
- Introducing ext3 – IBM developerWorks Advanced filesystem implementor's guide, Part 7
- Paragon ExtBrowser Free ext2/ext3 Windows driver
- Ext2 File System For Windows GPL ext2/ext3 file system driver for Windows 2000/XP/2003/VISTA/2008 (opensource, supports read & write, supports inode of 256 bytes at maximum to access larger disks)
- Ext2 Installable File System For Windows ext2/ext3 file system driver for MS Windows NT4.0/2000/XP/Vista/7/8/8.1/Server 2003/2008/2008 R2/2012/2012 R2 (freeware, closed source, supports read & write, supports inodes of 256 bytes at maximum to access larger disks)
- EXT2 IFS ext2/ext3 file system driver (read only) for MS Windows NT/2000/XP (opensource), latest version in the web archive
- Explore2fs An explorer-like GUI tool for accessing ext2/ext3 filesystems under MS Windows
- "Ext2read" A windows application to read/copy ext2/ext3/ext4 files with extent and LVM2 support.
- UFS Explorer Standard Recovery version 4 Commercial data recovery and file undelete software for Ext2/Ext3 file systems.
- ext2/ext3 resizing tools
- Presentation on EXT3 Journaling Filesystem by Dr. Stephen Tweedie at the Ottawa Linux Symposium, 20 July 2000
- State of the Art: Where we are with the Ext3 filesystem by Mingming Cao, Theodore Y. Ts'o, Badari Pulavarty, Suparna Bhattacharya, IBM Linux Technology Center, 2005
- Tutorial – Determining Your EXT3 Size Limits
- fuse-ext2 An open source ext2/ext3 file system driver for FUSE. (Supports Mac OS X 10.4 and later (Universal Binary), using MacFuse)
- Windows port of Ext2/Ext4 and other FS in CROSSMETA
- Red Hat Enterprise Linux, Chapter 22. Write Barriers.
- Linux clockpocalypse in 2038 is looming and there's no 'serious plan'