On Wed, 26 Jun 2019 at 08:04, Christoph Hellwig wrote:
> On Tue, Jun 25, 2019 at 08:13:29PM +0200, Andreas Gruenbacher wrote:
> > On Tue, 25 Jun 2019 at 12:50, Christoph Hellwig wrote:
> > >
> > > > That seems way more complicated. I'd much rather go with something
> > > > like may patch plus
On Tue, Jun 25, 2019 at 08:13:29PM +0200, Andreas Gruenbacher wrote:
> On Tue, 25 Jun 2019 at 12:50, Christoph Hellwig wrote:
> >
> > > That seems way more complicated. I'd much rather go with something
> > > like may patch plus maybe a big fat comment explaining that persisting
> > > the size
On Tue, 25 Jun 2019 at 12:50, Christoph Hellwig wrote:
>
> > That seems way more complicated. I'd much rather go with something
> > like may patch plus maybe a big fat comment explaining that persisting
> > the size update is the file systems job. Note that a lot of the modern
> > file systems
On Tue, 25 Jun 2019 at 11:57, Christoph Hellwig wrote:
> On Mon, Jun 24, 2019 at 08:22:43PM +0200, Andreas Gruenbacher wrote:
> > That would work, but I don't like how this leaves us with a vfs function
> > that updates i_size without bothering to dirty the inode very much.
>
> This isn't a VFS
> That seems way more complicated. I'd much rather go with something
> like may patch plus maybe a big fat comment explaining that persisting
> the size update is the file systems job. Note that a lot of the modern
> file systems don't use the VFS inode tracking for that, besides XFS
> that
On Mon, 24 Jun 2019 at 08:55, Christoph Hellwig wrote:
> At least for xfs we don't need the mark_inode_dirty at all. Can you
> solve your gfs2 requirements on top of something like the patch below?
> Note that in general it seems like you should try to only update the
> on-disk inode size in
At least for xfs we don't need the mark_inode_dirty at all. Can you
solve your gfs2 requirements on top of something like the patch below?
Note that in general it seems like you should try to only update the
on-disk inode size in writeback completion anyway, otherwise you can
have a stale i_size
On Tue, Jun 18, 2019 at 04:47:16PM +0200, Andreas Gruenbacher wrote:
> Remove the mark_inode_dirty call from __generic_write_end and add it to
> generic_write_end and the high-level iomap functions where necessary.
> That way, large writes will only dirty inodes at the end instead of
> dirtying
On Tue 18-06-19 16:47:16, Andreas Gruenbacher wrote:
> Remove the mark_inode_dirty call from __generic_write_end and add it to
> generic_write_end and the high-level iomap functions where necessary.
> That way, large writes will only dirty inodes at the end instead of
> dirtying them once per
Remove the mark_inode_dirty call from __generic_write_end and add it to
generic_write_end and the high-level iomap functions where necessary.
That way, large writes will only dirty inodes at the end instead of
dirtying them once per page. This fixes a performance bottleneck on
gfs2.
10 matches
Mail list logo
