Re: Rules for calling ->releasepage()

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

 



On Jun 4, 2015, at 2:39 AM, Jan Kara <jack@xxxxxxx> wrote:
> 
>  Hello,
> 
> we were recently debugging an issue where customer was hitting
> warnings in xfs_vm_releasepage() which was complaining that the
> page it was called for has delay-allocated buffers. After some
> debugging we realized that indeed try_to_release_page() call from
> shrink_active_list() can happen for a page in arbitrary state (that
> call happens only if buffer_heads_over_limit is set so that is
> the reason why we normally don't see that).
> 
> Hence comes my question: What are the rules for when releasepage()
> can be called? And what is the expected outcome? We are certainly
> guaranteed to hold page lock. try_to_release_page() also makes
> sure the page isn't under writeback.  But what is ->releasepage()
> supposed to do with a dirty page?
> Generally IFAIU we aren't supposed to discard dirty data but I
> wouldn't bet on all filesystems getting it right because the
> common call paths make sure page is clean. I would almost say we
> should enforce !PageDirty in try_to_release_page() if it was not
> for that ext3 nastyness of cleaning buffers under a dirty page -
> hum, but maybe the right answer for that is ripping ext3 out of
> tree (which would also allow us to get rid of some code in the
> blocklayer for bouncing journaled data buffers when stable writes
> are required).
> 
> Thoughts?

I've been an advocate of removing ext3 from the tree for a few years
already.  It doesn't do anything better than ext4, but it does a lot
of things worse.  Distros have been using CONFIG_EXT4_USE_FOR_EXT23
for several years now without problems AFAIK so this is safe even
if users don't want to upgrade their on-disk features in case they
want to be able to downgrade to an older kernel.

Cheers, Andreas





--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux