Re: [PATCH] bootfs: simple bootloader filesystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 02, 2019 at 08:46:32AM +1100, Dave Chinner wrote:
> On Mon, Apr 01, 2019 at 12:00:01AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@xxxxxxxxxx>
> > 
> > Does your computer use a bootloader which arrogantly declares that it can
> > read boot files off a filesystem but isn't sophisticated enough even to
> > recognize when that filesystem needs journal recovery?
> > 
> > Does your system software deployment program foolishly omit system calls
> > to flush newly unwrapped packages to disk?  Do you sometimes wonder if
> > they've forgotten that old maxim, "wait for the disk drive light to turn
> > off /before/ you power down"?
> > 
> > Are your computer operators aggressively derpy?  Do they have a habit of
> > leaving disk cables on the floor so they can trip over them twenty times
> > a day?  Does this leave you with sad files full of zeroes?
> > 
> > If so, bootfs is for you!  This new filesystem type uses journalling to
> > ensure metadata integrity, but forces all writes and directory tree
> > updates to be synchronous, fsyncs files on close, and checkpoints its
> > journal whenever a synchronization event happens.  Some allege this is
> > very slow, but I've been able to max out the iops on both of my double
> > height floppy drives!  In a power-cycling stress test, I found that the
> > switch broke off in my hand before I lost any data.  This concept may
> > sound terrible, but like any good crutch, it _is_ made of wood!
> > 
> > Singed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
>   ^^^^^^^^^^
> 
> Ooooo - such a hot topic! Finally bootfs is more than just
> we-really-should-do-this conference talk!
> 
> Looks good to me - with this we can finally move on from LILO....

When Ted is done laughing, I really would like to consider something
like this to solve the problem of grub-style bootloaders requiring a
lease on the blocks underneath a file with a term exceeding that of the
running kernel.

We can probably skip the harsh synchronous writes in favor of fsync on
close, but we would need to keep the critical component of checkpointing
the journal on fsync and syncfs.

> Acked-by: Dave Chinner <david@xxxxxxxxxxxxx>
> 
> FWIW, Should this have a cc: stable@xxxxxxxxxx tag on
> it so it gets out into distro-world ASAP?

Eh, I was going to let AI autoselect it...

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@xxxxxxxxxxxxx



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux