On Sat, Jun 01, 2019 at 08:45:49AM +1000, Dave Chinner wrote:
> Given that we can already use AIO to provide this sort of ordering,
> and AIO is vastly faster than synchronous IO, I don't see any point
> in adding complex barrier interfaces that can be /easily implemented
> in userspace/ using exis
On Fri, May 31, 2019 at 12:41:36PM -0400, Theodore Ts'o wrote:
> On Fri, May 31, 2019 at 06:21:45PM +0300, Amir Goldstein wrote:
> > What do you think of:
> >
> > "AT_ATOMIC_DATA (since Linux 5.x)
> > A filesystem which accepts this flag will guarantee that if the linked file
> > name exists after
31.05.2019, 23:05, "Joe Perches" :
> On Fri, 2019-05-31 at 22:53 +0300, Andrey Abramov wrote:
>> Fix -Wunused-but-set-variable warnings in raid56.c and sysfs.c files
> These uses seem boolean, so perhaps just use bool?
I used int because you use ints (as bools) everywhere (for example there is
On Fri, 2019-05-31 at 23:31 +0300, Andrey Abramov wrote:
> 31.05.2019, 23:05, "Joe Perches" :
> > On Fri, 2019-05-31 at 22:53 +0300, Andrey Abramov wrote:
> > > Fix -Wunused-but-set-variable warnings in raid56.c and sysfs.c files
> > These uses seem boolean, so perhaps just use bool?
> I used int
On Fri, 2019-05-31 at 22:53 +0300, Andrey Abramov wrote:
> Fix -Wunused-but-set-variable warnings in raid56.c and sysfs.c files
trivia:
> diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
> index f3d0576dd327..4ab29eacfdf3 100644
> --- a/fs/btrfs/raid56.c
> +++ b/fs/btrfs/raid56.c
> @@ -1182,22
Fix -Wunused-but-set-variable warnings in raid56.c and sysfs.c files
Signed-off-by: Andrey Abramov
---
fs/btrfs/raid56.c | 32 +++-
fs/btrfs/sysfs.c | 5 +
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
ind
On Fri, May 31, 2019 at 08:22:06PM +0300, Amir Goldstein wrote:
> >
> > This is I think more precise:
> >
> > This guarantee can be achieved by calling fsync(2) before linking
> > the file, but there may be more performant ways to provide these
> > semantics. In particular, note that t
On Fri, May 31, 2019 at 7:41 PM Theodore Ts'o wrote:
>
> On Fri, May 31, 2019 at 06:21:45PM +0300, Amir Goldstein wrote:
> > What do you think of:
> >
> > "AT_ATOMIC_DATA (since Linux 5.x)
> > A filesystem which accepts this flag will guarantee that if the linked file
> > name exists after a syste
On 31.05.19 г. 19:03 ч., David Sterba wrote:
> On Fri, May 31, 2019 at 06:01:14PM +0300, Nikolay Borisov wrote:
>> ---
>> fs/btrfs/volumes.c | 98 ++
>> fs/btrfs/volumes.h | 2 +
>> 2 files changed, 100 insertions(+)
>>
>> diff --git a/fs/btrfs/volum
Turn the comment about required lock into an assertion.
Signed-off-by: David Sterba
---
fs/btrfs/raid56.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 67a6f7d47402..505979d867e0 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/r
Turn the comment about required lock into an assertion.
Signed-off-by: David Sterba
---
fs/btrfs/delayed-ref.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/delayed-ref.c b/fs/btrfs/delayed-ref.c
index a73fc23e2961..a94fae897b3f 100644
--- a/fs/btrfs/delayed
The tree is going to be modified so it must be the exclusive lock.
Signed-off-by: David Sterba
---
fs/btrfs/ctree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 5df76c17775a..99a585ede79d 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/
Lockdep annotations are better than comments about necessary locks.
David Sterba (5):
btrfs: tests: add locks around add_extent_mapping
btrfs: assert extent map tree lock in add_extent_mapping
btrfs: assert tree mod log lock in __tree_mod_log_insert
btrfs: assert delayed ref lock in btrfs_
As add_extent_mapping is called from several functions, let's add the
lock annotation. The tree is going to be modified so it must be the
exclusive lock.
Signed-off-by: David Sterba
---
fs/btrfs/extent_map.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/e
There are no concerns about locking during the selftests so the locks
are not necessary, but following patches will add lockdep assertions to
add_extent_mapping so this is needed in tests too.
Signed-off-by: David Sterba
---
fs/btrfs/tests/extent-map-tests.c | 22 ++
1 file c
On Fri, May 31, 2019 at 06:21:45PM +0300, Amir Goldstein wrote:
> What do you think of:
>
> "AT_ATOMIC_DATA (since Linux 5.x)
> A filesystem which accepts this flag will guarantee that if the linked file
> name exists after a system crash, then all of the data written to the file
> and all of the
On Fri, May 31, 2019 at 06:01:14PM +0300, Nikolay Borisov wrote:
> ---
> fs/btrfs/volumes.c | 98 ++
> fs/btrfs/volumes.h | 2 +
> 2 files changed, 100 insertions(+)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 776f5c7ca7c5..b130f46
> >
> > So instead of saying "A filesystem that accepts this flag will
> > guaranty, that old inode data will not be exposed in the new linked
> > name." It's much clearer to state this in the affirmative:
> >
> > A filesystem which accepts this flag will guarantee that if
> > the
Presently btrfs_map_block is used not only to do everything necessary
to map a bio to the underlying allocation profile but it's also used to
identify how much data could be written based on btrfs' stripe logic
without actually submitting anything. This is achieved by passing NULL
for 'bbio_ret' pa
---
fs/btrfs/volumes.c | 98 ++
fs/btrfs/volumes.h | 2 +
2 files changed, 100 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 776f5c7ca7c5..b130f465ca6d 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -5907,6 +5907
On Wed, May 15, 2019 at 03:56:31PM +0100, Filipe Manana wrote:
> On Fri, May 10, 2019 at 12:30 AM Qu Wenruo wrote:
> > On 2019/5/9 下午10:49, David Sterba wrote:
> > > On Wed, May 08, 2019 at 06:49:58PM +0800, Qu Wenruo wrote:
> > >> [BUG]
> > >> The following script can cause unexpected fsync failu
On Fri, May 31, 2019 at 12:19:15PM +0300, Nikolay Borisov wrote:
> > {
> > - WARN_ON(atomic_read(&eb->spinning_writers));
> > - atomic_inc(&eb->spinning_writers);
> > + WARN_ON(eb->spinning_writers);
> > + eb->spinning_writers++;
> > }
> >
> > static void btrfs_assert_spinning_writers_
Gentle ping?
I didn't see this patch included in misc-next.
Anything went wrong?
Thanks,
Qu
On 2019/5/15 下午10:56, Filipe Manana wrote:
> On Fri, May 10, 2019 at 12:30 AM Qu Wenruo wrote:
>>
>>
>>
>> On 2019/5/9 下午10:49, David Sterba wrote:
>>> On Wed, May 08, 2019 at 06:49:58PM +0800, Qu Wenruo
On 30.05.19 г. 19:31 ч., David Sterba wrote:
> The write_locks is either 0 or 1 and always updated under the lock,
> so we don't need the atomic_t semantics.
>
> Signed-off-by: David Sterba
Generally looks good, though my remark for patch2 remains.
Reviewed-by: Nikolay Borisov
> ---
> fs/
On 30.05.19 г. 19:31 ч., David Sterba wrote:
> The spinning_writers is either 0 or 1 and always updated under the lock,
> so we don't need the atomic_t semantics.
>
> Signed-off-by: David Sterba
> ---
> fs/btrfs/extent_io.c | 2 +-
> fs/btrfs/extent_io.h | 2 +-
> fs/btrfs/locking.c|
On 30.05.19 г. 19:31 ч., David Sterba wrote:
> The blocking_writers is either 0 or 1 and always updated under the lock,
> so we don't need the atomic_t semantics.>
> Signed-off-by: David Sterba
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/extent_io.c | 2 +-
> fs/btrfs/extent_io.h | 2
26 matches
Mail list logo
