On Thu, Aug 29, 2019 at 8:57 AM Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > > On Thu, Aug 29, 2019 at 10:45:37PM +0800, UGlee wrote: > > Dear: > > > > We are using btrfs in an embedded arm/linux device. > > > > The bootloader (u-boot) has only limited support for btrfs. > > Occasionally the device lost power supply unexpectedly, leaving an > > inconsistent file system on eMMC. If I dump the partition image from > > eMMC and mount it on linux desktop, the file system is perfectly > > usable. What kernel messages do you get when trying to mount the mmc device? And also, does it mount ok with '-o ro,norecovery' ? And also I wonder if there is even a log tree, which you can discover with 'btrfs insp dump-s -f <dev>' and see if the log tree address is something other than 0. Anyway, point is, Btrfs gets to a certain point in the mount process and will try to do a write, and if that write fails, it complains. Writes could fail on the mmc device but succeed on the image file. Both eMMC and SD cards are dreadfully susceptible to failure with abrupt power supply loss, perhaps especially if writes are happening at the time of the loss (there probably is some research and better anecdotal information to support this contention). This topic comes up all the time on Hacker News and people who do this a lot swear by getting industrial grade flash for such embedded devices. This stuff is not cheap compared to consumer grade flash. It's decently likely the consumer grade stuff is optimized for exFAT, and the kind of sequential writes you get from photos and video being written out by a camera, rather than a file system like Btrfs (or even ext4 or XFS) containing an operating system, and writing system logs/journals, and doing updates, and things like that. > > > > My guess is that the linux kernel can fully handle the journalled > > update and garbage data. > > btrfs doesn't have a journal -- if the hardware is telling the > truth about barriers, and about written data reaching permanent > storage, then the FS structures on disk are always consistent. It's > got a log tree which is used for recovery of partial writes in the > case of a crash midway through a transaction, but that doesn't affect > the primary FS structures. Yeah and the log tree is per subvolume. A possible work around might be to separate things in their own subvolumes, thereby obviating the problem with a bootloader's lack of support for log tree replay. In that case rudimentary breakdown would be boot, root, home subvolumes at the top level of the file system, that way subvolid 5 isn't getting the log tree added, rather it'll be root or home - hopefully boot would be spared a log tree if writes weren't happening at the time of the power failure. Also, it's worth 'chattr +C' on the boot subvolume to ensure it's not subject to compression mount options, if the bootloader doesn't explicitly support compression. -- Chris Murphy
