On 7/5/19 12:13 PM, Darrick J. Wong wrote: > On Fri, Jul 05, 2019 at 11:08:54AM -0500, Eric Sandeen wrote: >> On 6/20/19 11:51 AM, Darrick J. Wong wrote: >>> From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> ... >>> + >>> +.PP >>> +.I flags >>> +can be one of the following: >>> +.RS 0.4i >>> +.TP >>> +.B XFS_FSOP_GOING_FLAGS_DEFAULT >>> +Flush all dirty data and in-core state to disk, flush pending transactions to >>> +the log, and shut down. >> >> What exactly do we mean by "in-core state" here? I'm not sure the average >> reader will know (I'm not sure I know) > > Hm... really it's any dirty cached state, like ... unflushed inodes and > dquots, dirty file data, etc. I didn't want to commit to that level of > specificity though. "Flush all dirty data and metadata to disk, flush pending transactions to the log, and shut down." ? >>> +.TP >>> +.B XFS_FSOP_GOING_FLAGS_LOGFLUSH >>> +Flush all pending transactions to the log and shut down, leaving all dirty >>> +data unwritten. >>> +.TP >>> +.B XFS_FSOP_GOING_FLAGS_NOLOGFLUSH >>> +Shut down immediately, without writing pending transactions or dirty data >>> +to disk. >>> + >>> +.SH RETURN VALUE >>> +On error, \-1 is returned, and >>> +.I errno >>> +is set to indicate the error. >>> +.PP >>> +.SH ERRORS >>> +Error codes can be one of, but are not limited to, the following: >> >> Hm crud, now I wonder about auditing all your stated error codes. >> EPERM, EFAULT, and EINVAL seem to be the only options for this >> particular call. Maybe that can be a 2nd cleanup, documenting >> an error code that won't happen is harmless... > > <urk> Ok, I'll go do that. :) > >>> +.TP >>> +.B EFSBADCRC >>> +Metadata checksum validation failed while performing the query. >>> +.TP >>> +.B EFSCORRUPTED >>> +Metadata corruption was encountered while performing the query. >>> +.TP >>> +.B EINVAL >>> +The specified allocation group number is not valid for this filesystem. > > This one definitely was copypasta error. :( Oh oopsies. Ok that's worth fixing .... -Eric
