On Tue, May 28, 2019 at 11:07 PM Darrick J. Wong
wrote:
>
> On Mon, May 27, 2019 at 08:26:55PM +0300, Amir Goldstein wrote:
> > New link flags to request "atomic" link.
> >
> > Signed-off-by: Amir Goldstein
> > ---
> >
> > Hi Guys,
> >
> > Following our discussions on LSF/MM and beyond [1][2], he
On Tue, May 28, 2019 at 11:27 PM Theodore Ts'o wrote:
>
> On Mon, May 27, 2019 at 08:26:55PM +0300, Amir Goldstein wrote:
> >
> > Following our discussions on LSF/MM and beyond [1][2], here is
> > an RFC documentation patch.
> >
> > Ted, I know we discussed limiting the API for linking an O_TMPFIL
On Tue, May 28, 2019 at 09:07:19PM -0700, Darrick J. Wong wrote:
> On Wed, May 29, 2019 at 12:02:40PM +0800, Shiyang Ruan wrote:
> > On 5/29/19 10:47 AM, Dave Chinner wrote:
> > > On Wed, May 29, 2019 at 10:01:58AM +0800, Shiyang Ruan wrote:
> > > > On 5/28/19 5:17 PM, Jan Kara wrote:
> > > > > I'm
On Wed, May 29, 2019 at 12:02:40PM +0800, Shiyang Ruan wrote:
>
>
> On 5/29/19 10:47 AM, Dave Chinner wrote:
> > On Wed, May 29, 2019 at 10:01:58AM +0800, Shiyang Ruan wrote:
> > >
> > > On 5/28/19 5:17 PM, Jan Kara wrote:
> > > > On Mon 27-05-19 16:25:41, Shiyang Ruan wrote:
> > > > > On 5/23/1
On 5/29/19 10:47 AM, Dave Chinner wrote:
On Wed, May 29, 2019 at 10:01:58AM +0800, Shiyang Ruan wrote:
On 5/28/19 5:17 PM, Jan Kara wrote:
On Mon 27-05-19 16:25:41, Shiyang Ruan wrote:
On 5/23/19 7:51 PM, Goldwyn Rodrigues wrote:
Hi,
I'm working on reflink & dax in XFS, here are some th
On Wed, May 29, 2019 at 10:01:58AM +0800, Shiyang Ruan wrote:
>
> On 5/28/19 5:17 PM, Jan Kara wrote:
> > On Mon 27-05-19 16:25:41, Shiyang Ruan wrote:
> > > On 5/23/19 7:51 PM, Goldwyn Rodrigues wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm working on reflink & dax in XFS, here are som
On 5/28/19 5:17 PM, Jan Kara wrote:
On Mon 27-05-19 16:25:41, Shiyang Ruan wrote:
On 5/23/19 7:51 PM, Goldwyn Rodrigues wrote:
Hi,
I'm working on reflink & dax in XFS, here are some thoughts on this:
As mentioned above: the second iomap's offset and length must match the
first. I thought
On Mon, May 27, 2019 at 08:26:55PM +0300, Amir Goldstein wrote:
>
> Following our discussions on LSF/MM and beyond [1][2], here is
> an RFC documentation patch.
>
> Ted, I know we discussed limiting the API for linking an O_TMPFILE
> to avert the hardlinks issue, but I decided it would be better
On Mon, May 27, 2019 at 08:26:55PM +0300, Amir Goldstein wrote:
> New link flags to request "atomic" link.
>
> Signed-off-by: Amir Goldstein
> ---
>
> Hi Guys,
>
> Following our discussions on LSF/MM and beyond [1][2], here is
> an RFC documentation patch.
>
> Ted, I know we discussed limiting
On 05/28/2019 15:54, Hugo Mills wrote:
>
>You have bad RAM.
>
On 05/28/2019 15:56, Hans van Kranenburg wrote:
> So, what you're observing here is a bitflip. One of the zeros flipped
> into a one, which caused the 14634 to suddenly become 268450090.
Indeed, I had RAM trouble some time ago.
Hi,
On 5/28/19 8:39 PM, Cesar Strauss wrote:
>
> After a BTRFS partition becoming read-only under use, it cannot be
> mounted anymore.
>
> The output is:
>
> # mount /dev/sdb5 /mnt/disk1
> mount: /mnt/disk1: wrong fs type, bad option, bad superblock on
> /dev/sdb5, missing codepage or helper
On Tue, May 28, 2019 at 03:39:36PM -0300, Cesar Strauss wrote:
> Hello,
>
> After a BTRFS partition becoming read-only under use, it cannot be
> mounted anymore.
>
> The output is:
>
> # mount /dev/sdb5 /mnt/disk1
> mount: /mnt/disk1: wrong fs type, bad option, bad superblock on
> /dev/sdb5, mis
Hello,
After a BTRFS partition becoming read-only under use, it cannot be
mounted anymore.
The output is:
# mount /dev/sdb5 /mnt/disk1
mount: /mnt/disk1: wrong fs type, bad option, bad superblock on
/dev/sdb5, missing codepage or helper program, or other error.
Kernel output:
[ 2042.106654
On Wed, May 15, 2019 at 04:03:17PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When syncing the log, the final phase of a fsync operation, we need to
> either create a log root's item or update the existing item in the log
> tree of log roots, and that depends on the current value
On Mon, May 20, 2019 at 09:57:00AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When doing an incremental send we can now issue clone operations with a
> source range that ends at the source's file eof and with a destination
> range that ends at an offset smaller then the destinati
On Wed, May 15, 2019 at 04:02:47PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When replaying a log that contains a new file or directory name that needs
> to be added to its parent directory, we end up updating the mtime and the
> ctime of the parent directory to the current time
On Thu, May 16, 2019 at 03:48:55PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> While logging an inode we follow its ancestors and for each one we mark
> it as logged in the current transaction, even if we have not logged it.
> As a consequence if we change an attribute of an ances
On Tue, May 14, 2019 at 01:54:37PM +0300, Nikolay Borisov wrote:
> While fixing the failing ASSERT in device replace finishing procedure I also
> found several oddities/bugs. Here is the resultant pile.
>
> First 3 patches are a couple simple cleanups.
>
> Patch 4 fixes a real bug since btrfs_in
INQUIRY_4178916..xlsx
Description: Binary data
On Tue, May 28, 2019 at 06:18:35PM +0800, Qu Wenruo wrote:
> CC: sta...@vger.kernel.org # 4.19
This is for 4.19 stable tree.
On Tue, May 28, 2019 at 06:15:52PM +0800, Qu Wenruo wrote:
> From: Josef Bacik
> CC: sta...@vger.kernel.org # 4.14
This applies to 4.14 stable tree.
> On 11 May 2019, at 11:24 PM, Steven Davies wrote:
>
> Tested-by: Steven Davies
>
> Series (inc. btrfs-progs changes) tested working as expected against current
> btrfs-devel and btrfs-progs/devel.
>
> Am I correct in thinking that if more than one devid is assigned as a
> readmirror, th
On 2019/5/28 下午9:45, Nikolay Borisov wrote:
>
>
> On 28.05.19 г. 16:24 ч., Qu Wenruo wrote:
>>
>>
>> On 2019/5/28 下午8:48, Nikolay Borisov wrote:
>>>
>>>
>>> On 28.05.19 г. 11:18 ч., Qu Wenruo wrote:
If a filesystem doesn't map its logical address space (normally the
bytenr/blocknr re
On 28.05.19 г. 16:24 ч., Qu Wenruo wrote:
>
>
> On 2019/5/28 下午8:48, Nikolay Borisov wrote:
>>
>>
>> On 28.05.19 г. 11:18 ч., Qu Wenruo wrote:
>>> If a filesystem doesn't map its logical address space (normally the
>>> bytenr/blocknr returned by fiemap) directly to its devices(s), the
>>> foll
On 2019/5/28 下午8:48, Nikolay Borisov wrote:
>
>
> On 28.05.19 г. 11:18 ч., Qu Wenruo wrote:
>> If a filesystem doesn't map its logical address space (normally the
>> bytenr/blocknr returned by fiemap) directly to its devices(s), the
>> following assumptions used in the test case is no longer t
On Tue, May 28, 2019 at 06:23:53PM +0800, Qu Wenruo wrote:
> From: Josef Bacik
>
> Commit 38e3eebff643db725633657d1d87a3be019d1018.
Thanks for the backports, now queued up.
greg k-h
Dear Dennis,
Without the bcache cache device, I was able to mount the file system (
root ) for read-only. I recreated it on the same LVM volume, and
rsync-ed the files. The files I lost (i/o error because checksum error)
was not important. Your case might be different. But without the cache,
On 28.05.19 г. 11:18 ч., Qu Wenruo wrote:
> If a filesystem doesn't map its logical address space (normally the
> bytenr/blocknr returned by fiemap) directly to its devices(s), the
> following assumptions used in the test case is no longer true:
> - trim range start beyond the end of fs should f
On 15/5/19 10:29 PM, David Sterba wrote:
On Fri, Mar 29, 2019 at 01:49:54PM +0800, Anand Jain wrote:
blkid_get_cache() returns error code which is -errno. So we can use them
directly.
Signed-off-by: Anand Jain
---
Ref:
blkid_get_cache() code:
https://github.com/karelzak/util-linux/blob/master/
On 15/5/19 10:26 PM, David Sterba wrote:
On Fri, Mar 29, 2019 at 01:49:53PM +0800, Anand Jain wrote:
@@ -386,7 +386,9 @@ static int cmd_device_scan(int argc, char **argv)
}
out:
- return !!ret;
+ if (ret < 0)
+ return -ret;
+ return ret;
No, cmd_de
> Am 28.05.2019 um 14:36 schrieb Christoph Anton Mitterer
> :
>
> Hey.
>
> Just to be on the safe side...
>
> AFAIU this issue only occured in 5.1.2 and later, right?
No. The issue was already introduced in v5.1-rc1 (commit 61697a6abd24).
> Starting with which 5.1.x and 5.2.x versions has t
Hey.
Just to be on the safe side...
AFAIU this issue only occured in 5.1.2 and later, right?
Starting with which 5.1.x and 5.2.x versions has the fix been merged?
Cheers,
Chris.
Dear Szalma!
Thank you for the information.
On Dienstag, 28. Mai 2019 08:40:40 CEST Szalma László wrote:
> I experienced the same, the problem is with bcache + gcc9. Immediately
> remove the cache device from the bcache, as it prevents more damages to
> your filesystem. After it downgrade gcc to
On 28.05.19 г. 11:21 ч., Qu Wenruo wrote:
> Normally the range->len is set to default value (U64_MAX), but when it's
> not default value, we should check if the range overflows.
>
> And if overflows, return -EINVAL before doing anything.
>
> Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Bori
On Dienstag, 28. Mai 2019 06:31:00 CEST Chris Murphy wrote:
> On Mon, May 27, 2019 at 3:33 PM Dennis Schridde wrote:
> > Yesterday I upgraded from Linux 5.1.1 (built with GCC 8.3.0) to Linux
> > 5.1.4
> > (built with GCC 9.1.0). The next boot was extremely slow and the desktop
> > environment (KD
From: Josef Bacik
Commit 38e3eebff643db725633657d1d87a3be019d1018.
Qgroups will do the old roots lookup at delayed ref time, which could be
while walking down the extent root while running a delayed ref. This
should be fine, except we specifically lock eb's in the backref walking
code irrespect
From: Josef Bacik
Commit 38e3eebff643db725633657d1d87a3be019d1018.
Qgroups will do the old roots lookup at delayed ref time, which could be
while walking down the extent root while running a delayed ref. This
should be fine, except we specifically lock eb's in the backref walking
code irrespect
From: Josef Bacik
Commit 38e3eebff643db725633657d1d87a3be019d1018.
Qgroups will do the old roots lookup at delayed ref time, which could be
while walking down the extent root while running a delayed ref. This
should be fine, except we specifically lock eb's in the backref walking
code irrespect
On Tue, May 21, 2019 at 07:28:08PM +0800, Qu Wenruo wrote:
> [BUG]
> When mounting a fs with reloc tree and has qgroup enabled, it can cause
> NULL pointer dereference at mount time:
> BUG: kernel NULL pointer dereference, address: 00a8
> #PF: supervisor read access in kernel mode
>
On Mon 27-05-19 16:25:41, Shiyang Ruan wrote:
> On 5/23/19 7:51 PM, Goldwyn Rodrigues wrote:
> > >
> > > Hi,
> > >
> > > I'm working on reflink & dax in XFS, here are some thoughts on this:
> > >
> > > As mentioned above: the second iomap's offset and length must match the
> > > first. I though
Normally the range->len is set to default value (U64_MAX), but when it's
not default value, we should check if the range overflows.
And if overflows, return -EINVAL before doing anything.
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent-tree.c | 14 +++---
1 file changed, 11 insertions(+),
If a filesystem doesn't map its logical address space (normally the
bytenr/blocknr returned by fiemap) directly to its devices(s), the
following assumptions used in the test case is no longer true:
- trim range start beyond the end of fs should fail
- trim range start beyond the end of fs with len
42 matches
Mail list logo
