[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    Re: [PATCH RFC v3 1/5] Revert "btrfs: add support for processing pending changes" related commits
From:       David Sterba <dsterba () suse ! cz>
Date:       2015-01-30 17:30:02
Message-ID: 20150130173001.GP3641 () twin ! jikos ! cz
[Download RAW message or body]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]