*** Disregard previous post. I read btrfs-map-logical.c, and the
reply below is more sensical than my last. I now understand since I
wasn't specifying a byte size to btrfs-map-logical, it was defaulting
to the nodesize which is 16k. Filefrag shows the first fragment is
128k, but below I discuss h
Reported at: https://bugzilla.kernel.org/show_bug.cgi?id=199707
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On martedì 8 maggio 2018 09:50:23 CEST, Rolf Wald wrote:
You need to build three partitions, e.g. named boot, swap, root.
You don't need to use an unencrypted boot if you use grub:
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29
A f
On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote:
> On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> > Right now we return EINVAL if a process does not have permission to dedupe a
> > file. This was an oversight on my part. EPERM gives a true description of
> > the natu
[spotted while going through ->d_fsdata handling around d_splice_alias();
don't really care which tree that goes through]
The only thing even looking at ->d_fsdata in there (since 2012)
had been kfree(dentry->d_fsdata) in btrfs_dentry_delete(). Which,
incidentally, is all btrfs_dentry_delete() do
Hey Adam,
On Sat, May 12, 2018 at 04:49:20AM +0200, Adam Borowski wrote:
> On Fri, May 11, 2018 at 12:26:50PM -0700, Mark Fasheh wrote:
> > The permission check in vfs_dedupe_file_range() is too coarse - We
> > only allow dedupe of the destination file if the user is root, or
> > they have the fil
On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote:
> On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> > Right now we return EINVAL if a process does not have permission to dedupe a
> > file. This was an oversight on my part. EPERM gives a true description of
> > the natu
On Sun, May 13, 2018 at 06:21:52PM +, Mark Fasheh wrote:
> On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote:
> > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote:
> > > Right now we return EINVAL if a process does not have permission to
> > > dedupe a
> > > file. This
On Sun, May 13, 2018 at 06:16:53PM +, Mark Fasheh wrote:
> On Sat, May 12, 2018 at 04:49:20AM +0200, Adam Borowski wrote:
> > On Fri, May 11, 2018 at 12:26:50PM -0700, Mark Fasheh wrote:
> > > The permission check in vfs_dedupe_file_range() is too coarse - We
> > > only allow dedupe of the dest
On Fri, May 11, 2018 at 11:12:18PM +0200, Jan Kara wrote:
> On Thu 10-05-18 16:13:58, Luis R. Rodriguez wrote:
> > The Linux VFS does not allow a way to set append/immuttable
> > attributes to symlinks, this is just not possible. If this is
> > detected inform the user as the filesystem must be cor
On Sat, May 12, 2018 at 8:09 PM, Chris Murphy wrote:
> On Sat, May 12, 2018 at 6:10 PM, james harvey
> wrote:
>> On Sat, May 12, 2018 at 3:51 AM, Martin Steigerwald
>> wrote:
>>> Hey James.
>>>
>>> james harvey - 12.05.18, 07:08:
100% reproducible, booting from disk, or even Arch installa
This patchset is mainly focused on fixing qgroup rescan corruption.
Since the whole btrfs qgroup is based on the modification between 2
transactions, it only has correct qgroup delta.
While if the rescan can't provide a correct result from the very
beginning, qgroup numbers are corrupted.
The pat
Under the following case, qgroup rescan can double account cowed tree
blocks:
In this case, extent tree only has one tree block.
-
| transid=5 last committed=4
| btrfs_qgroup_rescan_worker()
| |- btrfs_start_transaction()
| | transid = 5
| |- qgroup_rescan_leaf()
||- btrfs_search_slot_for_re
When doing qgroup rescan using the following script (modified from
btrfs/017 test case), we can sometimes hit qgroup corruption.
--
umount $dev &> /dev/null
umount $mnt &> /dev/null
mkfs.btrfs -f -n 64k $dev
mount $dev $mnt
extent_size=8192
xfs_io -f -d -c "pwrite 0 $extent_size" $mnt/foo >
On 2018年05月12日 13:08, james harvey wrote:
> 100% reproducible, booting from disk, or even Arch installation ISO.
> Kernel 4.16.7. btrfs-progs v4.16.
>
> Reading one of two journalctl files causes a kernel oops. Initially
> ran into it from "journalctl --list-boots", but cat'ing the file does
>
Filipe Manana 於 2018-05-11 17:59 寫到:
On Fri, May 11, 2018 at 7:34 AM, robbieko
wrote:
From: Robbie Ko
[BUG]
btrfs incremental send BUG happens when creating a snapshot of
snapshot
that is being used by send.
[REASON]
The problem can happen if while we are doing a send one of the
snapshots
From: Robbie Ko
[BUG]
btrfs incremental send BUG happens when creating a snapshot of snapshot
that is being used by send.
[REASON]
The problem can happen if while we are doing a send one of the snapshots
used (parent or send) is snapshotted, because snapshoting implies COWing
the root of the sou
On Sun, May 13, 2018 at 10:08 PM, Qu Wenruo wrote:
> On 2018年05月12日 13:08, james harvey wrote:
>> Hardware is fine. Passes memtest86+ in SMP mode. Works fine on all
>> other files.
>>
>>
>>
>> [ 381.869940] BUG: unable to handle kernel paging request at
>> 00390e50
>> [ 381.870881] BT
On 2018年05月14日 12:41, james harvey wrote:
> On Sun, May 13, 2018 at 10:08 PM, Qu Wenruo wrote:
>> On 2018年05月12日 13:08, james harvey wrote:
>>> Hardware is fine. Passes memtest86+ in SMP mode. Works fine on all
>>> other files.
>>>
>>>
>>>
>>> [ 381.869940] BUG: unable to handle kernel paging
On 2018年05月14日 13:30, Qu Wenruo wrote:
>
>
> On 2018年05月14日 12:41, james harvey wrote:
>> On Sun, May 13, 2018 at 10:08 PM, Qu Wenruo wrote:
>>> On 2018年05月12日 13:08, james harvey wrote:
Hardware is fine. Passes memtest86+ in SMP mode. Works fine on all
other files.
There is one report of compressed extent happens in btrfs, but has no
csum and then leads to possible decompress error screwing up kernel
memory.
Although it's a kernel bug, and won't cause problem until compressed
data get corrupted, let's catch such problem in advance.
This patch will catch any
There is one report of compressed extent happens in btrfs, but has no
csum and then leads to possible decompress error screwing up kernel
memory.
Although it's a kernel bug, and won't cause problem until compressed
data get corrupted, let's catch such problem in advance.
This patch will catch any
22 matches
Mail list logo
