On 18.06.19 г. 23:09 ч., Josef Bacik wrote:
> This is the first pass at making extent-tree.c much smaller. I've
> purposefully
> done no other cleanups or changes. The places where I needed to modify
> callers
> were done in separate patches. The only time I moved and changed callers in
> l
On 19.06.19 г. 20:47 ч., Josef Bacik wrote:
> This works for all callers already, but if we wanted to use the helper
> for the global_block_rsv it would end up trying to refill itself. Fix
> the logic to be able to be used no matter which block rsv is passed in
> to this helper.
>
> Signed-off
On 19.06.19 г. 20:47 ч., Josef Bacik wrote:
> block_rsv_release_bytes() is the internal to the block_rsv code, and
> shouldn't be called directly by anything else. Switch all users to the
> exported helpers.
>
> Signed-off-by: Josef Bacik
> ---
> fs/btrfs/extent-tree.c | 14 ++
>
On Thu, Jun 20, 2019 at 11:32:21AM +0300, Nikolay Borisov wrote:
>
>
> On 19.06.19 г. 20:47 ч., Josef Bacik wrote:
> > block_rsv_release_bytes() is the internal to the block_rsv code, and
> > shouldn't be called directly by anything else. Switch all users to the
> > exported helpers.
> >
> > Si
On Mon 10-06-19 21:46:25, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> When we're using FS_IOC_SETFLAGS to set the immutable flag on a file, we
> need to ensure that userspace can't continue to write the file after the
> file becomes immutable. To make that happen, we have to flush all the
On Mon 10-06-19 21:46:45, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
> metadata can
On Tue, Jun 18, 2019 at 10:59:18AM -0400, Josef Bacik wrote:
> We have been seeing issues in production where a cleaner script will end
> up unlinking a bunch of files that have pending iputs. This means they
> will get their final iput's run at btrfs-cleaner time and thus are not
> throttled, whi
On Wed, Jun 19, 2019 at 01:05:50PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> If the range for which we are punching a hole covers only part of a page,
> we end up updating the inode item but we skip the update of the inode's
> iversion, mtime and ctime. Fix that by ensuring we u
On Wed, Jun 19, 2019 at 01:05:39PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> In order to avoid searches on a log tree when unlinking an inode, we check
> if the inode being unlinked was logged in the current transaction, as well
> as the inode of its parent directory. When any o
Move these bits first as they are the easiest to move. Export two of
the helpers so they can be moved all at once.
Signed-off-by: Josef Bacik
---
fs/btrfs/Makefile | 2 +-
fs/btrfs/block-group.c | 99 ++
fs/btrfs/block-group.h | 7
fs/
These are relatively straightforward as well.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 83 ++
fs/btrfs/block-group.h | 6
fs/btrfs/ctree.h | 6
fs/btrfs/extent-tree.c | 82 ---
We'll need this to move the caching stuff around.
Signed-off-by: Josef Bacik
---
fs/btrfs/ctree.h | 3 +++
fs/btrfs/extent-tree.c | 40 +---
2 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index c4ae6
Man a lot of people use this stuff.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.h | 3 +++
fs/btrfs/extent-tree.c | 36 ++--
2 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/fs/btrfs/block-group.h b/fs/btrfs/block-group.h
index c8a63ccd6b5
Another easy set to move over to block-group.c.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 24
fs/btrfs/block-group.h | 2 ++
fs/btrfs/ctree.h | 3 ---
fs/btrfs/extent-tree.c | 25 -
4 files changed, 26 insertions(+), 28 delet
We can now easily migrate this code as well.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 174 +
fs/btrfs/extent-tree.c | 174 -
2 files changed, 174 insertions(+), 174 deletions(-)
diff -
This gets used by a few different logical chunks of the block group
code, export it while we move things around.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.h | 2 ++
fs/btrfs/extent-tree.c | 8
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/block-group.
This can easily be moved now.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 196 +
fs/btrfs/block-group.h | 2 +
fs/btrfs/ctree.h | 2 -
fs/btrfs/extent-tree.c | 196 -
4 files cha
This is used in caching and reading block groups, so export it while we
move these chunks independently.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.h | 1 +
fs/btrfs/extent-tree.c | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/block-group.h b/fs/bt
These feel more at home in block-group.c.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 100 ++
fs/btrfs/block-group.h | 16 +++
fs/btrfs/ctree.h | 4 --
fs/btrfs/extent-tree.c | 115 -
This is prep work for moving block_group_cache around. Having this in
the header file makes the header file include need to be in a certain
order, which is awkward, so just move it into free-space-cache.c and
then we can re-arrange later.
Signed-off-by: Josef Bacik
---
fs/btrfs/free-space-cache
This is the series to migrate the block group code out of extent-tree.c. This
is a much larger series than the previous two series because things were much
more intertwined than block_rsv's and space_info. There is one code change
patch in this series, it is
btrfs: make caching_thread use btrfs_
Want to move these functions into block-group.c, so export them.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.h | 6 ++
fs/btrfs/extent-tree.c | 21 ++---
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/block-group.h b/fs/btrfs/block-group.h
This can now be easily migrated as well.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 140 +
fs/btrfs/block-group.h | 2 +
fs/btrfs/ctree.h | 2 -
fs/btrfs/extent-tree.c | 140 -
These were renamed and exported to facilitate logical migration of
different code chunks into block-group.c. Now that all the users are in
one file go ahead and rename them back, move the code around, and make
them static.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 140
All of the prep work has been done so we can now cleanly move this chunk
over.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 613 +
fs/btrfs/block-group.h | 5 +
fs/btrfs/ctree.h | 5 -
fs/btrfs/extent-tree.c | 611 -
This is prep work for moving all of the block group cache code into its
own file.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.h | 156 +
fs/btrfs/ctree.h | 148 +--
fs/btrfs/disk-io.c
This belongs to block-group.c, move it over.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 141 +
fs/btrfs/block-group.h | 1 +
fs/btrfs/ctree.h | 1 -
fs/btrfs/extent-tree.c | 141 ---
This can be easily migrated over now.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 520 +
fs/btrfs/block-group.h | 3 +
fs/btrfs/ctree.h | 3 -
fs/btrfs/extent-tree.c | 518
4 fi
This is the removal code and the unused bgs code.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 509 +
fs/btrfs/block-group.h | 7 +
fs/btrfs/ctree.h | 7 -
fs/btrfs/extent-tree.c | 505 --
This will make it so we can move them easily.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.h | 14 +++
fs/btrfs/extent-tree.c | 65 ++
2 files changed, 43 insertions(+), 36 deletions(-)
diff --git a/fs/btrfs/block-group.h b/fs/btrfs
We can now just copy it over to block-group.c.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c | 463 +
fs/btrfs/block-group.h | 2 +
fs/btrfs/ctree.h | 2 -
fs/btrfs/extent-tree.c | 461 -
This feels more at home in block-group.c than in extent-tree.c.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.c| 247 ++
fs/btrfs/block-group.h| 24 +
fs/btrfs/ctree.h | 24 -
fs/btrfs/delalloc-space.c | 1 +
fs/btrfs
extent-tree.c has a find_next_key that just walks up the path to find
the next key, but it is used for both the caching stuff and the snapshot
delete stuff. The snapshot deletion stuff is special so it can't really
use btrfs_find_next_key, but the caching thread stuff can. We just need
to fix btr
This is used in a few logical parts of the block group code, temporarily
export it so we can move things in pieces.
Signed-off-by: Josef Bacik
---
fs/btrfs/block-group.h | 2 ++
fs/btrfs/extent-tree.c | 15 ---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs
This gets used directly by a bunch of the block group code, export it to
make it easier to move things around.
Signed-off-by: Josef Bacik
---
fs/btrfs/ctree.h | 1 +
fs/btrfs/extent-tree.c | 16
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/ctree
On Thu, Jun 20, 2019 at 04:03:45PM +0200, Jan Kara wrote:
> On Mon 10-06-19 21:46:45, Darrick J. Wong wrote:
> > From: Darrick J. Wong
> >
> > The chattr manpage has this to say about immutable files:
> >
> > "A file with the 'i' attribute cannot be modified: it cannot be deleted
> > or renamed,
On Mon, Jun 10, 2019 at 09:46:17PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> The chattr manpage has this to say about immutable files:
>
> "A file with the 'i' attribute cannot be modified: it cannot be deleted
> or renamed, no link can be created to this file, most of the file's
On Thu, Jun 20, 2019 at 04:00:28PM +0200, Jan Kara wrote:
> On Mon 10-06-19 21:46:25, Darrick J. Wong wrote:
> > From: Darrick J. Wong
> >
> > When we're using FS_IOC_SETFLAGS to set the immutable flag on a file, we
> > need to ensure that userspace can't continue to write the file after the
> >
On Thu, Jun 20, 2019 at 05:52:12PM -0400, Theodore Ts'o wrote:
> On Mon, Jun 10, 2019 at 09:46:17PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong
> >
> > The chattr manpage has this to say about immutable files:
> >
> > "A file with the 'i' attribute cannot be modified: it cannot be de
Hello,
I have a new corruption on another Arch Linux server with a simple root btrfs
filesystem on an SSD.
The SSD has no corruption. Looks like the server crashed and rebooted. But the
next reboot failed because there is error with filesytem check.
Here is some info about the FS:
# btrfs fi sh
On Thu, Jun 20, 2019 at 03:13:06PM -0700, Darrick J. Wong wrote:
> > I note that this patch doesn't allow writes to swap files. So Amir's
> > generic/554 test will still fail for those file systems that don't use
> > copy_file_range.
>
> I didn't add any IS_SWAPFILE checks here, so I'm not sure t
41 matches
Mail list logo