I'm still running into this with 5.0.0-rc6 and sssd. I'm not sure what
the issue is but it often does prevent sssd from starting up, so
that's not good.
https://bugzilla.redhat.com/show_bug.cgi?id=1677163
[ 53.313230] localhost.localdomain polkitd[721]: Started polkitd version 0.115
[ 53.46095
On Thu, Feb 14, 2019 at 1:06 AM Chris Murphy wrote:
>
> I'm still running into this with 5.0.0-rc6 and sssd. I'm not sure what
> the issue is but it often does prevent sssd from starting up, so
> that's not good.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1677163
Actually, sssd fails without
On 2/13/19 1:23 AM, David Sterba wrote:
The member btrfs_fs_info::scrub_nocow_workers is unused since the nocow
optimization was removed from scrub in 9bebe665c3e4 ("btrfs: scrub:
Remove unused copy_nocow_pages and its callchain").
Signed-off-by: David Sterba
Reviewed-by: Anand Jain
--
From: Omar Sandoval
Now that we have a btime iattr, use it to allow updating btime from
utimensat(). We do so by adding a new AT_UTIME_BTIME flag. Iff this flag
is given, the btime is set to times[2] (unless times is NULL, in which
case the current time is used).
Signed-off-by: Omar Sandoval
--
From: Omar Sandoval
The ext4 inode format includes btime (under the name crtime) if the
inode is large enough (256 bytes).
Signed-off-by: Omar Sandoval
---
fs/ext4/inode.c | 15 +--
fs/ext4/super.c | 2 +-
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/ino
From: Omar Sandoval
Signed-off-by: Omar Sandoval
---
man2/utimensat.2 | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/man2/utimensat.2 b/man2/utimensat.2
index d61b43e96..3b7c62181 100644
--- a/man2/utimensat.2
+++ b/man2/utimensat.2
@@
From: Omar Sandoval
The f2fs inode format includes btime (under the name crtime) if the
feature was enabled at mkfs time.
Signed-off-by: Omar Sandoval
---
fs/f2fs/file.c | 19 +++
fs/f2fs/super.c | 2 +-
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/
From: Omar Sandoval
Add btime as an attribute that can be updated through notify_change() if
the filesystem supports it, which is indicated by FS_HAS_BTIME in
file_system_type->fs_flags.
Signed-off-by: Omar Sandoval
---
fs/attr.c | 6 ++
include/linux/fs.h | 4
2 files change
From: Omar Sandoval
Hi,
Since statx was added in 4.11, userspace has had an interface for
reading btime (file creation time), but no way to set it. This RFC patch
series adds support for changing btime with utimensat(). Patch 1 adds
the VFS infrastructure, patch 2 adds the support to utimensat()
From: Omar Sandoval
The Btrfs inode format has always included btime (under the name otime),
so setting it is trivial.
Signed-off-by: Omar Sandoval
---
fs/btrfs/inode.c | 2 ++
fs/btrfs/super.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs
From: Omar Sandoval
In order to test updating btime, make the utimes command optionally take
the btime timestamp.
Signed-off-by: Omar Sandoval
---
io/utimes.c | 41 +++--
man/man8/xfs_io.8 | 5 +++--
2 files changed, 34 insertions(+), 12 deletions(-)
From: Omar Sandoval
Test that on filesystems supporting btime, the timestamp is updated as
expected.
Signed-off-by: Omar Sandoval
---
common/rc | 14 ++
tests/generic/526 | 64 +++
tests/generic/526.out | 14 ++
tests/gene
From: Omar Sandoval
The XFS inode format includes btime (under the name crtime) in inode
version 3. Also update the comments in libxfs to reflect that di_crtime
can now change.
Signed-off-by: Omar Sandoval
---
fs/xfs/libxfs/xfs_format.h | 2 +-
fs/xfs/libxfs/xfs_log_format.h | 2 +-
fs/x
Hello,
I'm not sure this is the right forum to ask on but I'll try and if its
not I do apologize. I have also created a stack overflow question
without success (
https://stackoverflow.com/questions/54634703/btrfs-send-with-parent-different-size-depending-on-source-of-files
) but ill paste the
Hello Fellow BTRFS users.
I have run into the bad key order issue.
corrupt leaf: root=1 block=57567265079296 slot=83, bad key order, prev
(18446744073709551605 0 57707594776576) current (18446726481523507189
0 57709742260224)
The lines repeats over and over..
I read a thread between Hugo Mills an
On Thu, 2019-02-14 at 01:22 +, Filipe Manana wrote:
> The following one liner fixes it:
> https://friendpaste.com/22t4OdktHQTl0aMGxcWLj3
Great to see that fixed... is there any advise that can be given for
users/admins?
Like whether and how any occurred corruptions can be detected (right
now
On 2019/2/14 下午7:58, Jesper Utoft wrote:
> Hello Fellow BTRFS users.
>
> I have run into the bad key order issue.
> corrupt leaf: root=1 block=57567265079296 slot=83, bad key order, prev
> (18446744073709551605 0 57707594776576) current (18446726481523507189
> 0 57709742260224)
> The lines repea
On Thu, Feb 14, 2019 at 08:25:26PM +0800, Qu Wenruo wrote:
> On 2019/2/14 下午7:58, Jesper Utoft wrote:
> > Hello Fellow BTRFS users.
> >
> > I have run into the bad key order issue.
> > corrupt leaf: root=1 block=57567265079296 slot=83, bad key order, prev
> > (18446744073709551605 0 57707594776576
On 2019/2/14 下午8:35, Hugo Mills wrote:
> On Thu, Feb 14, 2019 at 08:25:26PM +0800, Qu Wenruo wrote:
>> On 2019/2/14 下午7:58, Jesper Utoft wrote:
>>> Hello Fellow BTRFS users.
>>>
>>> I have run into the bad key order issue.
>>> corrupt leaf: root=1 block=57567265079296 slot=83, bad key order, prev
On 13.02.19 г. 17:55 ч., Nikolay Borisov wrote:
> This commit changes the implementation of cow_file_range_async in order
> to get rid of the BUG_ON in the middle of the loop. Additionally it
> reworks the inner loop in the hopes of making it more understandable.
>
> Main change is that the num
From: Filipe Manana
In the past we had data corruption when reading compressed extents that
are shared within the same file and they are consecutive, this got fixed
by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and
shared extents") and by commit 808f80b46790f ("Btrfs: update
From: Filipe Manana
Regression test for read corruption of compressed and shared extents after
punching holes into a file. The same extent is shared by the same file in
consecutive ranges (without other extents in between).
This is motivated by a bug recently found in btrfs for which there is a
On 13/02/2019 15:32, Hans van Kranenburg wrote:
[...]
>> +++ b/fs/btrfs/volumes.c
>> @@ -6794,7 +6794,7 @@ static int btrfs_check_chunk_valid(struct
>> btrfs_fs_info *fs_info,
>> (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes < 1) ||
>> (type & BTRFS_BLOCK_GROUP_RAID5 && num_str
On 2/13/19 3:37 PM, Johannes Thumshirn wrote:
> On 13/02/2019 15:32, Hans van Kranenburg wrote:
> [...]
>
>>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>>> index 03f223aa7194..b40cc7c830f4 100644
>>> --- a/fs/btrfs/volumes.c
>>> +++ b/fs/btrfs/volumes.c
>>> @@ -6794,7 +6794,7 @@ static
On Thu, Feb 14, 2019 at 02:00:07AM -0800, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Hi,
>
> Since statx was added in 4.11, userspace has had an interface for
> reading btime (file creation time), but no way to set it. This RFC patch
> series adds support for changing btime with utimensat().
On Thu, Feb 14, 2019 at 4:37 AM André Malm wrote:
>
> Hello,
>
> I'm not sure this is the right forum to ask on but I'll try and if its
> not I do apologize. I have also created a stack overflow question
> without success (
> https://stackoverflow.com/questions/54634703/btrfs-send-with-parent-diff
On Fri, Feb 15, 2019 at 09:06:26AM +1100, Dave Chinner wrote:
> On Thu, Feb 14, 2019 at 02:00:07AM -0800, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > Hi,
> >
> > Since statx was added in 4.11, userspace has had an interface for
> > reading btime (file creation time), but no way to set i
From: Darrick J. Wong
d_tmpfile was introduced to instantiate an inode in the dentry cache as
a temporary file. This helper decrements the inode's nlink count and
dirties the inode, presumably so that filesystems could call new_inode
to create a new inode with nlink == 1 and then call d_tmpfile
On Thu, Feb 14, 2019 at 03:14:29PM -0800, Omar Sandoval wrote:
> On Fri, Feb 15, 2019 at 09:06:26AM +1100, Dave Chinner wrote:
> > On Thu, Feb 14, 2019 at 02:00:07AM -0800, Omar Sandoval wrote:
> > > From: Omar Sandoval
> > >
> > > Hi,
> > >
> > > Since statx was added in 4.11, userspace has had
Hi,
On 2/14/19 11:00 AM, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Since statx was added in 4.11, userspace has had an interface for
> reading btime (file creation time), but no way to set it. This RFC patch
> series adds support for changing btime with utimensat(). Patch 1 adds
> the VFS i
> It doesn't work this way. The snapshots a and b are not based on the
> same underlying subvolume. The gist is that you would keep changing A,
> and take additional snapshots of A, such as a.1 a.2 a.3, and you can
> do incremental send with 'btrfs send -p a.1 a.2' which describes the
> difference
On Fri, Feb 15, 2019 at 01:57:39AM +, Hans van Kranenburg wrote:
> Hi,
>
> On 2/14/19 11:00 AM, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > Since statx was added in 4.11, userspace has had an interface for
> > reading btime (file creation time), but no way to set it. This RFC patch
On Thu, Feb 14, 2019 at 01:21:29PM +0100, Christoph Anton Mitterer wrote:
> On Thu, 2019-02-14 at 01:22 +, Filipe Manana wrote:
> > The following one liner fixes it:
> > https://friendpaste.com/22t4OdktHQTl0aMGxcWLj3
>
> Great to see that fixed... is there any advise that can be given for
> us
On Fri, Feb 15, 2019 at 11:16:57AM +1100, Dave Chinner wrote:
> On Thu, Feb 14, 2019 at 03:14:29PM -0800, Omar Sandoval wrote:
> > On Fri, Feb 15, 2019 at 09:06:26AM +1100, Dave Chinner wrote:
> > > On Thu, Feb 14, 2019 at 02:00:07AM -0800, Omar Sandoval wrote:
> > > > From: Omar Sandoval
> > > >
On 2019/1/31 下午10:36, David Sterba wrote:
> On Thu, Jan 31, 2019 at 08:45:42AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2019/1/30 下午11:19, David Sterba wrote:
>>> On Fri, Jan 25, 2019 at 01:09:17PM +0800, Qu Wenruo wrote:
+static int __must_check flush_write_bio(struct extent_page_data *epd)
35 matches
Mail list logo
