All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Cc: dsterba@suse.cz, linux-btrfs@vger.kernel.org, miaoxie@huawei.com
Subject: Re: [PATCH RFC v3 1/5] Revert "btrfs: add support for processing pending changes" related commits
Date: Fri, 30 Jan 2015 18:30:02 +0100	[thread overview]
Message-ID: <20150130173001.GP3641@twin.jikos.cz> (raw)
In-Reply-To: <54C989A0.1080307@cn.fujitsu.com>

On Thu, Jan 29, 2015 at 09:15:12AM +0800, Qu Wenruo wrote:
> > Are we sure that there's no possible deadlock when we eg. change the
> > label via sysfs in the middle of a balance that removes some of the
> > files? Or other combination of operations. Can we guarantee that this
> > will be ok in the long term and not introduced accidentally?
> For me, I didn't see the difference between VFS staff and sysfs/kernfs 
> staff.
> They both have their own locking things which is out of the control of 
> btrfs.

VFS is a close neighbor in the layering, syscalls come through it,
affects filesystem state very often and API changes propagate to all the
filesystems.

Sysfs provides us some API but in a very limited scope compared to VFS.

> But we are still using VFS staffs, right? If we want to use sysfs 
> interfaces to do things like change label,
> then it's our responsibility to ensure things works fine.

I absolutelly agree with that and that's why I'm trying to minimize the
potential traps when the subsystems become interconnected too closely,
eg.  depending on internal locks.

> If not we 
> should either modify btrfs or sysfs to
> do it, just like what we were doing with VFS staffs.

This means changing innternal workings of the two, this seems unlikely
as we're mere users for them. Though we can bring new requests for API
or some such, we can't easily affect their internal logic just because
it's easy for us to throw a transaction commit somewhere and stop
caring.

> To ensure the cooperation works fine, we just need extra testcases, much 
> like what we were doing.
> 
> So IMHO, I didn't really see the difference between VFS and sysfs staffs 
> (except sysfs is not so wided adapted).
> We just needs to do all the old style work, modify btrfs or sysfs or 
> both and, and add tons of test case.

And I see a big difference, if nothing else, sysfs is user of VFS layer.

  reply	other threads:[~2015-01-30 17:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-23  9:31 [PATCH RFC v3 0/5] mount options consistent enhancement Qu Wenruo
2015-01-23  9:31 ` [PATCH RFC v3 1/5] Revert "btrfs: add support for processing pending changes" related commits Qu Wenruo
2015-01-23 14:57   ` David Sterba
2015-01-26  0:37     ` Qu Wenruo
2015-01-26  6:05       ` Qu Wenruo
2015-01-28 13:25         ` David Sterba
2015-01-29  1:15           ` Qu Wenruo
2015-01-30 17:30             ` David Sterba [this message]
2015-01-23  9:31 ` [PATCH RFC v3 2/5] btrfs: Make btrfs_parse_options() parse mount option in a atomic way Qu Wenruo
2015-01-23  9:31 ` [PATCH RFC v3 3/5] btrfs: Introduce per-transaction mount_opt to keep mount option consistent during transaction Qu Wenruo
2015-01-23  9:31 ` [PATCH RFC v3 4/5] btrfs: Use btrfs_test_trans_opt() to handle SPACE_CACHE if it's under transaction protect Qu Wenruo
2015-01-23  9:31 ` [PATCH RFC v3 5/5] btrfs: Use btrfs_test_trans_opt() to handle INODE_CACHE " Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150130173001.GP3641@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=miaoxie@huawei.com \
    --cc=quwenruo@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.