Re: [git pull] first batch of ufs fixes

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sat, Jun 10, 2017 at 05:07:38PM +0100, Al Viro wrote:
> On Sat, Jun 10, 2017 at 06:03:24AM -0700, Richard Narron wrote:
> 
> > 2) After creating a new filesystem on FreeBSD, then on Linux copying a
> > larger than 2GB file and creating a directory, the fsck back on FreeBSD
> > looks ok.
> > 
> > But after going back to Linux and removing the large file and removing the
> > directory, the fsck on FreeBSD looks not so good:
> 
> What happens is ufs_evict_inode() buggering off without syncing the inode
> in case of final removal.  Incremental on top of that branch is
> diff --git a/fs/ufs/inode.c b/fs/ufs/inode.c
> index 34f11cf0900a..da553ffec85b 100644
> --- a/fs/ufs/inode.c
> +++ b/fs/ufs/inode.c
> @@ -848,6 +848,7 @@ void ufs_evict_inode(struct inode * inode)
>  		    (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
>  		     S_ISLNK(inode->i_mode)))
>  			ufs_truncate_blocks(inode);
> +		ufs_update_inode(inode, inode_needs_sync(inode));
>  	}
>  
>  	invalidate_inode_buffers(inode);
> 
> Committed and pushed out...

BTW, should I send an updated pull request in such situation?  It's the
same branch with the one-liner above added on top, head should be
at 67a70017fa0a152657bc7e337e69bb9c9f5549bf, stats
Al Viro (8):
      ufs: restore proper tail allocation
      fix ufs_isblockset()
      ufs: restore maintaining ->i_blocks
      ufs: set correct ->s_maxsize
      ufs_extend_tail(): fix the braino in calling conventions of ufs_new_fragments()
      ufs_getfrag_block(): we only grab ->truncate_mutex on block creation path
      excessive checks in ufs_write_failed() and ufs_evict_inode()
      ufs: we need to sync inode before freeing it

 fs/stat.c       |  1 +
 fs/ufs/balloc.c | 26 +++++++++++++++++++++++++-
 fs/ufs/inode.c  | 28 ++++++++++++----------------
 fs/ufs/super.c  | 18 ++++++++++++++++++
 fs/ufs/util.h   | 10 +++++++---
 5 files changed, 63 insertions(+), 20 deletions(-)

If you prefer the full git-request-pull output (I've no idea what kind
of scripts you are using and how much PITA do they prevent), please
yell.