Re: [PATCH 1/1] xfs: fallback to readonly during recovery

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

 



On Tue, Feb 11, 2020 at 08:29:59AM -0600, Eric Sandeen wrote:
> On 2/11/20 8:04 AM, Vincent Fazio wrote:
> > All,
> 
> ...
> 
> > As mentioned in the commit message, the SSDs we work with are ATA devices and there is no such mechanism in the ATA spec to report to the block layer that the device is RO. What we run into is this:
> > 
> > xfs_log_mount
> >     xfs_log_recover
> >         xfs_find_tail
> >             xfs_clear_stale_blocks
> >                 xlog_write_log_records
> >                     xlog_bwrite
> > 
> > the xlog_bwrite fails and triggers the call to xfs_force_shutdown.

If your device doesn't accept write requests then mark it read only.

--D

> > In this specific scenario, we know the log is clean as
> > XFS_MOUNT_WAS_CLEAN is set in the log flags, however the stale
> > blocks cannot be removed due to the device being write-protected.
> > the call to xfs_clear_stale_blocks cannot be obviated because, as
> > mentioned before, ATA devices do not have a mechanism to report that
> > they're read-only.
> 
> Ok, at least now we see where the writes are coming from.  A device that
> is /marked/ readonly won't get into xfs_clear_stale_blocks.  I'm not sure
> if we could just skip the xfs_clear_stale_blocks call if XFS_MOUNT_WAS_CLEAN
> is set, or if head == tail and no recovery is needed.  If so, then maybe
> rearranging the call to xfs_clear_stale_blocks could help.  I'll let people
> who know more log details than I do chime in on that though.
> 
> -Eric



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux