No functional change. First set the usual case, writeable then check
for any special config.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 5a4c30451c7f..a81574dba124 10064
Move uuid_mutex closer to the exclusion section.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index a81574dba124..a7eb9b42cd92 100644
--- a/fs/btrfs/volumes.c
+++ b/f
Assign ret = -EINVAL where actually its required.
Remove { } around single line if else code.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index a7eb9b42cd92..ba06a4ccd5a6
On Fri, 15 Dec 2017 01:39:03 +0100
Ian Kumlien wrote:
> Hi,
>
> Running a 4.14.3 kernel, this just happened, but there should have
> been another 20 gigs or so available.
>
> The filesystem seems fine after a reboot though
What are your mount options, and can you show the output of "btrfs fi
d
We call btrfs_free_stale_device() only when we alloc a new
struct btrfs_device (ret=1), so move it closer to where we
alloc the new device. Also drop the comments.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/fs/btrfs
On Mon, Dec 11, 2017 at 03:10:22PM -0800, Randy Dunlap wrote:
> > +A freshly-initialised XArray contains a ``NULL`` pointer at every index.
> > +Each non-``NULL`` entry in the array has three bits associated with
> > +it called tags. Each tag may be flipped on or off independently of
> > +the othe
Support for a new command is being added here:
btrfs dev ignore [dev]
This cli/ioctl is needed as there is no way to continue to mount in
degraded mode if the device is already scanned, which is required to
recover from the split brain raid conditions.
This patch proposes to use ioctl #5 as it w
Now as the there is path in arg, so instead of reading the path from
cur_device just get it from the caller, and so the purpose of cur_device
is to skip the device, so rename it to skip_dev. Also drop the comment
about different path being used for the same device, since now we will
have cli to cle
On Thu, Dec 14, 2017 at 5:39 PM, Ian Kumlien wrote:
> Hi,
>
> Running a 4.14.3 kernel, this just happened, but there should have
> been another 20 gigs or so available.
>
> The filesystem seems fine after a reboot though
>
> [1070034.614893] [ cut here ]
> [1070034.614899]
Let the list iterator iterate further and find other stale
devices and delete it. This is in preparation to add support
for user land request-able stale devices cleanup.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
This updates btrfs_free_stale_device() helper function to delete all
unmouted devices, when arg is NULL.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 70db6a1d5658.
There is no need to check for btrfs_fs_devices::seeding when we
have checked for btrfs_fs_devices::opened, because we can't sprout
without its seed FS being opened.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs
The btrfs_free_stale_device() is updated to match for the given
device path and delete it. (It searchs for only unmounted list of
devices.)
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/vol
We can reuse the function btrfs_free_stale_device() to add feature
to forget a scanned device or all stale devices. So this patch set
proposes following changes to it.
Anand Jain (6):
btrfs: cleanup btrfs_free_stale_device() usage
btrfs: no need to check for btrfs_fs_devices::seeding
btrfs:
This patch adds cli
btrfs device forget [dev]
which shall remove the relevant device entries in the kernel
matching the dev. If no argument is given it shall remove all
stale (device which are not mounted) from the kernel.
This uses ioctl BTRFS_IOC_IGNORE_DEV to remove a device and
sets BTRFS_D
Adds cli and ioctl to forget a scanned device or forget all stale
devices in the kernel.
v5:
Adds feature to delete all stale devices
Reuses btrfs_free_stale_devices() fn and so depends on the
patch-set [1] in the ML.
Uses struct btrfs_ioctl_vol_args_v2 instead of
struct btrfs_ioctl_
On Fri, Dec 15, 2017 at 12:53 AM, Jan Kara wrote:
> On Thu 14-12-17 22:30:26, Yan, Zheng wrote:
>> On Thu, Dec 14, 2017 at 9:43 PM, Jan Kara wrote:
>> > On Thu 14-12-17 18:55:27, Yan, Zheng wrote:
>> >> We recently got an Oops report:
>> >>
>> >> BUG: unable to handle kernel NULL pointer derefere
Hi,
Running a 4.14.3 kernel, this just happened, but there should have
been another 20 gigs or so available.
The filesystem seems fine after a reboot though
[1070034.614893] [ cut here ]
[1070034.614899] WARNING: CPU: 4 PID: 18634 at fs/btrfs/inode.c:4647
btrfs_truncate_i
[remove stable@ as this is not really a stable patch]
On Dec 14, 2017, at 7:30 AM, Yan, Zheng wrote:
>
> On Thu, Dec 14, 2017 at 9:43 PM, Jan Kara wrote:
>> On Thu 14-12-17 18:55:27, Yan, Zheng wrote:
>>> We recently got an Oops report:
>>>
>>> BUG: unable to handle kernel NULL pointer derefer
On 12/13, Adam Borowski wrote:
> This link is replicated in most filesystems' config stanzas. Referring
> to an archived version of that site is pointless as it mostly deals with
> patches; user documentation is available elsewhere.
>
> Signed-off-by: Adam Borowski
> ---
> Sending this as one pi
On Mon, 2017-12-11 at 14:43 -0800, Matthew Wilcox wrote:
> - There's no warning for the first paragraph of section 6:
>
> 6) Functions
>
>
> Functions should be short and sweet, and do just one thing. They should
> fit on one or two screenfuls of text (the ISO/ANSI screen size is 8
On Thu 14-12-17 22:30:26, Yan, Zheng wrote:
> On Thu, Dec 14, 2017 at 9:43 PM, Jan Kara wrote:
> > On Thu 14-12-17 18:55:27, Yan, Zheng wrote:
> >> We recently got an Oops report:
> >>
> >> BUG: unable to handle kernel NULL pointer dereference at (null)
> >> IP: jbd2__journal_start+0x38/0x1a2
> >>
On Wed, Dec 13, 2017 at 01:50:07PM +0200, Nikolay Borisov wrote:
> Commit e0ae99941423 ("btrfs: preallocate device flush bio") reworked
> the way the flush bio is allocated and used. Concretely it allocates
> the bio in __alloc_device and then re-uses it multiple times with a
> very simple endio ro
On Wed, Dec 13, 2017 at 09:38:14AM +0200, Nikolay Borisov wrote:
> Signed-off-by: Nikolay Borisov
Added, thanks.
--
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
On Thu, 14 Dec 2017 15:21:52 +0200
Nikolay Borisov wrote:
> On 14.12.2017 13:02, Dmitrii Tcvetkov wrote:
> > Since 4.15-rc1 if btrfs filesystem is mounted with flushoncommit mount
> > option then during fsync this trace appears in dmesg:
> >
> > [ 17.323092] WARNING: CPU: 0 PID: 364 at fs/fs-w
On Thu, Dec 14, 2017 at 9:43 PM, Jan Kara wrote:
> On Thu 14-12-17 18:55:27, Yan, Zheng wrote:
>> We recently got an Oops report:
>>
>> BUG: unable to handle kernel NULL pointer dereference at (null)
>> IP: jbd2__journal_start+0x38/0x1a2
>> [...]
>> Call Trace:
>> ext4_page_mkwrite+0x307/0x52b
>
On Thu, Dec 14, 2017 at 05:23:33PM +0900, Misono, Tomohiro wrote:
> Summary:
> Cleanup mount path by avoiding calling btrfs_mount() twice.
> No functional changes. See below for longer explanation.
>
> Changelog:
> v4:
> - Rebased to v4.15-rc3
> - Change MS_* flags to SB_* flags
> -
On Thu 14-12-17 18:55:27, Yan, Zheng wrote:
> We recently got an Oops report:
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: jbd2__journal_start+0x38/0x1a2
> [...]
> Call Trace:
> ext4_page_mkwrite+0x307/0x52b
> _ext4_get_block+0xd8/0xd8
> do_page_mkwrite+0x6e/0xd8
On Thu, Dec 14, 2017 at 03:21:52PM +0200, Nikolay Borisov wrote:
>
>
> On 14.12.2017 13:02, Dmitrii Tcvetkov wrote:
> > Since 4.15-rc1 if btrfs filesystem is mounted with flushoncommit mount
> > option
> > then during fsync this trace appears in dmesg:
> >
> > [ 17.323092] WARNING: CPU: 0 PID
I send:
[PATCH] Btrfs: make should_defrag_range() understood compressed extents
If you want you can test that, it fix btrfs fi def and autodefrag
behavior with compressed data.
Also it understood if user try recompress data with old/new compression algo.
2017-12-14 14:27 GMT+03:00 Timofey Titovet
Compile tested and "battle" tested
2017-12-14 16:35 GMT+03:00 Timofey Titovets :
> Both, defrag ioctl and autodefrag - call btrfs_defrag_file()
> for file defragmentation.
>
> Kernel target extent size default is 256KiB
> Btrfs progs by default, use 32MiB.
>
> Both bigger then max (not fragmented)
Both, defrag ioctl and autodefrag - call btrfs_defrag_file()
for file defragmentation.
Kernel target extent size default is 256KiB
Btrfs progs by default, use 32MiB.
Both bigger then max (not fragmented) compressed extent size 128KiB.
That lead to rewrite all compressed data on disk.
Fix that an
Ignore that patch please, i will send another
2017-12-14 2:25 GMT+03:00 Timofey Titovets :
> Defrag heuristic use extent lengh as threshold,
> kernel autodefrag use SZ_256KiB and btrfs-progs use SZ_32MiB as
> target extent lengh.
>
> Problem:
> Compressed extents always have lengh at < 128KiB (BTR
On Thu 14-12-17 18:55:27, Yan, Zheng wrote:
> We recently got an Oops report:
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: jbd2__journal_start+0x38/0x1a2
> [...]
> Call Trace:
> ext4_page_mkwrite+0x307/0x52b
> _ext4_get_block+0xd8/0xd8
> do_page_mkwrite+0x6e/0xd8
On 14.12.2017 13:02, Dmitrii Tcvetkov wrote:
> Since 4.15-rc1 if btrfs filesystem is mounted with flushoncommit mount option
> then during fsync this trace appears in dmesg:
>
> [ 17.323092] WARNING: CPU: 0 PID: 364 at fs/fs-writeback.c:2339
> __writeback_inodes_sb_nr+0xbf/0xd0
> [ 17.32392
2017-12-14 8:58 GMT+03:00 Duncan <1i5t5.dun...@cox.net>:
> Timofey Titovets posted on Thu, 14 Dec 2017 02:05:35 +0300 as excerpted:
>
>> Also, same problem exist for autodefrag case i.e.:
>> write 4KiB at start of compressed file autodefrag code add that file to
>> autodefrag queue, call btrfs_defr
Since 4.15-rc1 if btrfs filesystem is mounted with flushoncommit mount option
then during fsync this trace appears in dmesg:
[ 17.323092] WARNING: CPU: 0 PID: 364 at fs/fs-writeback.c:2339
__writeback_inodes_sb_nr+0xbf/0xd0
[ 17.323925] Modules linked in:
[ 17.324697] CPU: 0 PID: 364 Comm:
We recently got an Oops report:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: jbd2__journal_start+0x38/0x1a2
[...]
Call Trace:
ext4_page_mkwrite+0x307/0x52b
_ext4_get_block+0xd8/0xd8
do_page_mkwrite+0x6e/0xd8
handle_mm_fault+0x686/0xf9b
mntput_no_expire+0x1f/0x21e
On 2017/12/13 13:38, Adam Borowski wrote:
> This link is replicated in most filesystems' config stanzas. Referring
> to an archived version of that site is pointless as it mostly deals with
> patches; user documentation is available elsewhere.
>
> Signed-off-by: Adam Borowski
[skip]
> diff --g
Long ago, commit edf24abe51493 ("btrfs: sanity mount option parsing and
early mount code") split the btrfs_parse_options() into two parts
(btrfs_parse_early_options() and btrfs_parse_options()). As a result,
btrfs_parse_optins no longer gets called twice and is the last one to parse
mount option st
Since setup_root_args() is not used anymore, just remove it.
Signed-off-by: Tomohiro Misono
---
fs/btrfs/super.c | 36
1 file changed, 36 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index f0ecba7a1190..7da78cb8a946 100644
--- a/fs/btrfs/sup
Now parse_early_options() is used by both btrfs_mount() and
btrfs_mount_root(). However, the former only needs subvol related part
and the latter needs the others.
Therefore extract the subvol related parts from parse_early_options() and
move it to new parse function (parse_subvol_options()).
Sig
Add btrfs_mount_root() and new file_system_type for preparation of cleanup
of btrfs_mount(). Code path is not changed yet.
btrfs_mount_root() is almost the same as current btrfs_mount(), but doesn't
have subvolume related part.
Signed-off-by: Tomohiro Misono
---
fs/btrfs/super.c | 116 +
Cleanup btrfs_mount() by using btrfs_mount_root(). This avoids getting
btrfs_mount() called twice in mount path.
Old btrfs_mount() will do:
0. VFS layer calls vfs_kern_mount() with registered file_system_type
(for btrfs, btrfs_fs_type). btrfs_mount() is called on the way.
1. btrfs_parse_early_o
Summary:
Cleanup mount path by avoiding calling btrfs_mount() twice.
No functional changes. See below for longer explanation.
Changelog:
v4:
- Rebased to v4.15-rc3
- Change MS_* flags to SB_* flags
- Change GFP_NOFS to GFP_KERNEL
- Use if statements instead of switch in parse_ea
45 matches
Mail list logo
