On Mon, Feb 05, 2018 at 02:45:21PM +0800, Anand Jain wrote: > On 02/05/2018 02:38 PM, Anand Jain wrote: > > On 02/03/2018 03:09 AM, Howard McLauchlan wrote: > >> Presently, failing a primary super block write but succeeding in at > >> least one super block write in general will appear to users as if > >> nothing important went wrong. > > > >> However, upon unmounting and re-mounting, > >> the file system will be in a rolled back state. > > > > Right.! In case of non-datasync-IO, or where applications depend on the > > transcation_commit() to confirm the IO. > > > > David, Qu, > > > > In this context (single disk btrfs, the write to primary SB has > > been failing but read is fine), if a system is rebooted and continues > > the production the data loss is eminent!!!. btrfs_err() won't help to > > avoid the data loss nor we could blame the user for not taking any > > action on the btrfs_err(). > > I am wrong. I missed the return -1 which this patch adds. Which > means it is choice a. as below. But IMO better would have been > choice b. though.
I'm concerned about the cases where automatically mounting from the 2nd superblock would make thigs worse, and IIRC there are not enough data to decide in the mount callback. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
