On 22.04.19 г. 23:37 ч., Nathan Dehnel wrote:
> I have a raid10 volume that frequently locks up when I try to write to
> it or delete things. Any command that touches it will hang (and can't
> be killed) and I have to start a new ssh session to get into the
> computer again. Nothing fixes it bes
On Mon, Apr 22, 2019 at 2:38 PM Nathan Dehnel wrote:
>
> I have a raid10 volume that frequently locks up when I try to write to
> it or delete things. Any command that touches it will hang (and can't
> be killed) and I have to start a new ssh session to get into the
> computer again. Nothing fixes
On 2019/4/23 上午5:09, Jakob Unterwurzacher wrote:
> I have a user who is reporting ENOSPC errors when running gocryptfs on
> top of btrfs (ticket: https://github.com/rfjakob/gocryptfs/issues/395 ).
>
> What is interesting is that the error gets thrown at write time. This
> is not supposed to happ
I have a user who is reporting ENOSPC errors when running gocryptfs on
top of btrfs (ticket: https://github.com/rfjakob/gocryptfs/issues/395 ).
What is interesting is that the error gets thrown at write time. This
is not supposed to happen, because gocryptfs does
fallocate(..., FALLOC_FL_KEEP
I have a raid10 volume that frequently locks up when I try to write to
it or delete things. Any command that touches it will hang (and can't
be killed) and I have to start a new ssh session to get into the
computer again. Nothing fixes it besides a reboot, and the volume will
fail to unmount while
From: Filipe Manana
Stress send running in parallel with balance and deduplication against
files that belong to the snapshots used by send. The goal is to verify
that these operations running in parallel do not lead to send crashing
(trigger assertion failures and BUG_ONs), or send finding an inc
From: Filipe Manana
Send always operates on read-only trees and always expected that while it
is in progress, nothing changes in those trees. Due to that expectation
and the fact that send is a read-only operation, it operates on commit
roots and does not hold transaction handles. However relocat
From: Filipe Manana
Send operates on read only trees and expects them to never change while it
is using them. This is part of its initial design, and this expection is
due to two different reasons:
1) When it was introduced, no operations were allowed to modifiy read-only
subvolumes/snapshots
Signed-off-by: Nikolay Borisov
---
fs/btrfs/file-item.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
index 7e2cd9c81eb1..fa5057a4b53a 100644
--- a/fs/btrfs/file-item.c
+++ b/fs/btrfs/file-item.c
@@ -412,6 +412,16 @@ int btrfs_lookup_c
There are a couple of places in the code which need to ensure that a particular
range is locked and doesn't have pending ordered extents. Currently this logic
is
open-coded in said places. This patchset refactors the code such that we now
have btrfs_lock_and_flush_ordered_range which encompasses
There is a certain idiom used in multiple places in btrfs' codebase,
dealing with flushing an ordered range. Factor this in a separate
function that can be reused. Future patches will replace the existing
code with that function.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ordered-data.c | 32 ++
In case no cached_state argument is passed to
btrfs_lock_and_flush_ordered_range use one locally in the function. This
optimises the case when an ordered extent is found since the unlock
function will be able to unlock that state directly without searching
for it again.
Signed-off-by: Nikolay Bori
There several functions which open code
btrfs_lock_and_flush_ordered_range, just replace them with a call
to the function. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 27 +++
fs/btrfs/file.c | 14 ++
fs/btrfs/inode.c
13 matches
Mail list logo
