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.
