Also, since you don't have any snapshots, you could also find this
conventionally:
# du -sh /*
Chris Murphy
On Tue, Oct 30, 2018 at 4:44 PM, Barbet Alain wrote:
> Thanks for answer !
> alian@alian:~> sudo btrfs sub list -ta /
> [sudo] Mot de passe de root :
> ID gen top level path
> -- --- -
> 257 79379 5 /@
> 258 79386 257
On Tue, Oct 30, 2018 at 4:11 PM, Mirko Klingmann wrote:
> Hi all,
>
> my btrfs root file system on a SD card broke down and did not mount anymore.
It might mount with -o ro,nologreplay
Typically an SD card will break in a way that it can't write, and
mount will just hang (with mmcblk errors).
From: Omar Sandoval
There's a race between close_ctree() and cleaner_kthread().
close_ctree() sets btrfs_fs_closing(), and the cleaner stops when it
sees it set, but this is racy; the cleaner might have already checked
the bit and could be cleaning stuff. In particular, if it deletes unused
On 2018/10/31 上午4:11, Mirko Klingmann wrote:
> Hi all,
>
> my btrfs root file system on a SD card broke down and did not mount anymore.
>
> In retrospective, I think it reached its endurance, so I know that there
> is nothing to repair. All I want to do is to salvage some configuration
> and
On Tue, Oct 30, 2018 at 12:06:21PM -0700, Nick Terrell wrote:
> From: Jennifer Liu
>
> Adds zstd compression level support to btrfs. Zstd requires
> different amounts of memory for each level, so the design had
> to be modified to allow set_level() to allocate memory. We
> preallocate one
Thanks for answer !
alian@alian:~> sudo btrfs sub list -ta /
[sudo] Mot de passe de root :
ID gen top level path
-- --- -
257 79379 5 /@
258 79386 257 @/var
259 79000 257 @/usr/local
260 79376
Hi all,
my btrfs root file system on a SD card broke down and did not mount anymore.
In retrospective, I think it reached its endurance, so I know that there
is nothing to repair. All I want to do is to salvage some configuration
and data files from the remains left in my ISO file copy. The SD
From: Jennifer Liu
Adds zstd compression level support to btrfs. Zstd requires
different amounts of memory for each level, so the design had
to be modified to allow set_level() to allocate memory. We
preallocate one workspace of the maximum size to guarantee
forward progress. This feature is
On Sat, Oct 27, 2018 at 01:53:48AM +0100, Phillip Potter wrote:
> Deduplicate the btrfs file type conversion implementation - file systems
> that use the same file types as defined by POSIX do not need to define
> their own versions and can use the common helper functions decared in
> fs_types.h
On Tue, Oct 30, 2018 at 9:17 AM, Barbet Alain wrote:
> Hi,
> I experienced disk out of space issue:
> alian:~ # df -h
> Filesystem Size Used Avail Use% Mounted on
> devtmpfs7.8G 0 7.8G 0% /dev
> tmpfs 7.8G 47M 7.8G 1% /dev/shm
> tmpfs 7.8G 18M 7.8G
On Wed, Oct 24, 2018 at 08:24:03PM +0800, Lu Fengqi wrote:
> When running generic/475, we may get the following warning in the dmesg.
>
> [ 6902.102154] WARNING: CPU: 3 PID: 18013 at fs/btrfs/extent-tree.c:9776
> btrfs_free_block_groups+0x2af/0x3b0 [btrfs]
> [ 6902.104886] Modules linked in:
On Tue, Oct 30, 2018 at 10:10 AM, Ulli Horlacher
wrote:
>
> On Mon 2018-10-29 (17:57), Remi Gauvin wrote:
>> On 2018-10-29 02:11 PM, Ulli Horlacher wrote:
>>
>> > I want to know how many free space is left and have problems in
>> > interpreting the output of:
>> >
>> > btrfs filesystem usage
>> >
On Fri, Oct 26, 2018 at 05:15:21PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Tracking pending ordered extents per transaction was introduced in commit
> 50d9aa99bd35 ("Btrfs: make sure logged extents complete in the current
> transaction V3") and later updated in commit
On Fri, Oct 26, 2018 at 09:26:40PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> The logged_start and logged_end variables, at btrfs_log_changed_extents(),
> were added in commit 8c6c592831a0 ("btrfs: log csums for all modified
> extents"). However since the recent simplification
On 10/30/2018 12:10 PM, Ulli Horlacher wrote:
On Mon 2018-10-29 (17:57), Remi Gauvin wrote:
On 2018-10-29 02:11 PM, Ulli Horlacher wrote:
I want to know how many free space is left and have problems in
interpreting the output of:
btrfs filesystem usage
btrfs filesystem df
btrfs filesystem
On Tue, Oct 30, 2018 at 06:04:04PM +0800, robbieko wrote:
> From: Robbie Ko
>
> When the cow_file_range fail, the related resources are
> unlocked according to the range (start-end), so the unlock
> cannot be repeated in run_delalloc_nocow.
>
> In some cases (e.g. cur_offset <= end &&
On Mon 2018-10-29 (17:57), Remi Gauvin wrote:
> On 2018-10-29 02:11 PM, Ulli Horlacher wrote:
>
> > I want to know how many free space is left and have problems in
> > interpreting the output of:
> >
> > btrfs filesystem usage
> > btrfs filesystem df
> > btrfs filesystem show
>
> In my not
Hi,
I experienced disk out of space issue:
alian:~ # df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs7.8G 0 7.8G 0% /dev
tmpfs 7.8G 47M 7.8G 1% /dev/shm
tmpfs 7.8G 18M 7.8G 1% /run
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
This patch lands the last case which needs to be handled by the fsid
change code. Namely, this is the case where a multidisk filesystem has
already undergone at least one successful fsid change i.e all disks
have the METADATA_UUID incompat bit and power failure occurs as another
fsid change is in
This commit continues hardening the scanning code to handle cases where
power loss could have caused disks in a multi-disk filesystem to be
in inconsistent state. Namely handle the situation that can occur when
some of the disks in multi-disk fs have completed their fsid change i.e
they have
Even though fsid change without rewrite is a very quick operations it's
still possible to experience a split brain scenario if power loss
occurs at the right time. This patch handle the case where power
failure occurs while the first transaction (the one setting
CHANGING_FSID_V2) flag is being
In order to gracefully handle split-brain scenario which are very
unlikely, yet possible, while performing the FSID change I'm
gonna need two more pieces of information:
1. The highest generation number among all devices registered to a
particular btrfs_fs_devices
2. A boolean flag whether a
This field is going to be used when the user wants to change the UUID
of the filesystem without having to rewrite all metadata blocks. This
field adds another level of indirection such that when the FSID is
changed what really happens is the current UUID (the one with which the
fs was created) is
Currently btrfs_fs_info structure contains a copy of the
fsid/metadata_uuid fields. Same values are also contained in the
btrfs_fs_devices structure which fs_info has a reference to. Let's
reduce duplication by removing the fields from fs_info and always refer
to the ones in fs_devices. No
Here is the 3rd submission for the kernel counterpart of the uuid change
patchset. The only difference is that I (hope) have adressed all cosmetic
feedback from David as well as have reworded some change logs to ease
understanding. I've also re-run the regression tests and no failure were
On Mon, Oct 29, 2018 at 6:46 PM Hugo Mills wrote:
>
> On Mon, Oct 29, 2018 at 05:57:10PM -0400, Remi Gauvin wrote:
> > On 2018-10-29 02:11 PM, Ulli Horlacher wrote:
> > > I want to know how many free space is left and have problems in
> > > interpreting the output of:
> > >
> > > btrfs filesystem
On Tue, Oct 30, 2018 at 10:05 AM robbieko wrote:
>
> From: Robbie Ko
>
> When the cow_file_range fail, the related resources are
> unlocked according to the range (start-end), so the unlock
> cannot be repeated in run_delalloc_nocow.
>
> In some cases (e.g. cur_offset <= end && cow_start!= -1),
On Tue, Oct 30, 2018 at 7:00 AM robbieko wrote:
>
> From: Robbie Ko
>
> In apply_children_dir_moves, we first create an empty list (stack),
> then we get an entry from pending_dir_moves and add it to the stack,
> but we didn't delete the entry from rb_tree.
>
> So, in add_pending_dir_move, we
For any recent kernel, there is a chance that btrfs/057 reports false
errors.
The false error would look like:
btrfs/057 4s ... - output mismatch (see
/home/adam/xfstests-dev/results//btrfs/057.out.bad)
--- tests/btrfs/057.out 2017-08-21 09:25:33.1 +0800
+++
From: Robbie Ko
When the cow_file_range fail, the related resources are
unlocked according to the range (start-end), so the unlock
cannot be repeated in run_delalloc_nocow.
In some cases (e.g. cur_offset <= end && cow_start!= -1),
cur_offset is not updated correctly, so move the cur_offset
Hi,
this is a pre-release of btrfs-progs, 4.19-rc1. The version 4.18 was skipped to
keep the time of release close to kernel. The sort-of promise that
'progs version X supports features from kernel X' does not hold for the user
accessible ioctls to list subvolumes. As this is not a critical
On 30.10.18 г. 11:07 ч., Qu Wenruo wrote:
> For any recent kernel, there is a chance that btrfs/057 reports false
> errors.
>
> The false error would look like:
> btrfs/057 4s ... - output mismatch (see
> /home/adam/xfstests-dev/results//btrfs/057.out.bad)
> --- tests/btrfs/057.out
For any recent kernel, there is a chance that btrfs/057 reports false
errors.
The false error would look like:
btrfs/057 4s ... - output mismatch (see
/home/adam/xfstests-dev/results//btrfs/057.out.bad)
--- tests/btrfs/057.out 2017-08-21 09:25:33.1 +0800
+++
From: Robbie Ko
In apply_children_dir_moves, we first create an empty list (stack),
then we get an entry from pending_dir_moves and add it to the stack,
but we didn't delete the entry from rb_tree.
So, in add_pending_dir_move, we create a new entry and then use the
parent_ino in the current
35 matches
Mail list logo
