Chris Murphy:
> I wasn't aware that SUSE was now using the @ location for
> snapshots, or that it was using Btrfs for /home. For a
> while it's been XFS with a Btrfs sysroot.
Ours does use btrfs for `/' and xfs for `/home' *except*
`/home/hana', which is strange and wonderful, because the
On Mon, Oct 15, 2018 at 3:26 PM, Anton Shepelev wrote:
> Chris Murphy to Anton Shepelev:
>
>> > How can I track down the origin of this mount point:
>> >
>> > /dev/sda2 on /home/hana type btrfs
>> > (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana)
>> >
>> > if it is
On Mon, Oct 15, 2018 at 6:29 AM, Austin S. Hemmelgarn
wrote:
> On 2018-10-13 18:28, Chris Murphy wrote:
>> The end result is creating two Btrfs volumes would yield image files
>> with matching hashes.
>
> So in other words, you care about matching the block layout _exactly_.
Only because that's
Chris Murphy to Anton Shepelev:
> > How can I track down the origin of this mount point:
> >
> > /dev/sda2 on /home/hana type btrfs
> > (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana)
> >
> > if it is not present in /etc/fstab? I shouldn't like to
> > find/grep
On Mon, Oct 15, 2018 at 9:05 AM, Anton Shepelev wrote:
> Hello, all
>
> How can I track down the origin of this mount point:
>
>/dev/sda2 on /home/hana type btrfs
> (rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana)
>
> if it is not present in /etc/fstab? I
On 15.10.2018 09:25, Lu Fengqi wrote:
> The find_ref_head shouldn't return the first entry even if no exact match
> is found. So move the hidden behavior to higher level.
>
> Besides, remove the useless local variables in the btrfs_select_ref_head.
>
> Signed-off-by: Lu Fengqi
Reviewed-by:
Hello!
I am trying to figure out how to recover from errors detected by btrfs scrub.
Scrub status reports:
scrub status for 4f4479d5-648a-45b9-bcbf-978c766aeb41
scrub started at Mon Oct 15 10:02:28 2018, running for 00:35:39
total bytes scrubbed: 791.15GiB with 18 errors
The find_ref_head shouldn't return the first entry even if no exact match
is found. So move the hidden behavior to higher level.
Besides, remove the useless local variables in the btrfs_select_ref_head.
Signed-off-by: Lu Fengqi
---
fs/btrfs/delayed-ref.c | 45
From: Filipe Manana
Test that if we have a very small file, with a size smaller than the
block size, then fallocate a very small range within the block size but
past the file's current size, fsync the file and then power fail, after
mounting the filesystem all the file data is there and the file
From: Filipe Manana
When using the NO_HOLES feature and logging a regular file, we were
expecting that if we find an inline extent, that either its size in ram
(uncompressed and unenconded) matches the size of the file or if it does
not, that it matches the sector size and it represents
From: Filipe Manana
This test was using the "mktemp -d" command to create a temporary
directory for storing send streams and computations from fssum, without
ever deleting them when it finishes. Therefore after running it for many
times it filled up all space from /tmp.
Fix this by using a
On 2018/10/15 下午3:50, Otto Kekäläinen wrote:
> Hello!
>
> I am trying to figure out how to recover from errors detected by btrfs scrub.
>
> Scrub status reports:
>
> scrub status for 4f4479d5-648a-45b9-bcbf-978c766aeb41
> scrub started at Mon Oct 15 10:02:28 2018, running for 00:35:39
On 2018-10-13 18:28, Chris Murphy wrote:
Is it practical and desirable to make Btrfs based OS installation
images reproducible? Or is Btrfs simply too complex and
non-deterministic? [1]
The main three problems with Btrfs right now for reproducibility are:
a. many objects have uuids other than
On 2018-10-14 07:08, waxhead wrote:
In case BTRFS fails to WRITE to a disk. What happens?
Does the bad area get mapped out somehow? Does it try again until it
succeed or until it "times out" or reach a threshold counter?
Does it eventually try to write to a different disk (in case of using
the
On Mon, Oct 15, 2018 at 10:39:19AM +0800, Lu Fengqi wrote:
> On Thu, Oct 11, 2018 at 01:51:37PM +0200, David Sterba wrote:
> >On Thu, Oct 11, 2018 at 01:40:32PM +0800, Lu Fengqi wrote:
> >> There is no functional change. Just improve readablity.
> >>
> >> PATCH 1-4 parameter cleanup patches
> >>
The loop construct in free_extent_buffer was added in
242e18c7c1a8 ("Btrfs: reduce lock contention on extent buffer locks")
as means of reducing the times the eb lock is taken, the non-last ref
count is decremented and lock is released. As the special handling
of UNMAPPED extent buffers was
Hello, all
While trying to resolve free space problems, and found that
I cannot interpret the output of:
> btrfs filesystem show
Label: none uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
Total devices 1 FS bytes used 34.06GiB
devid1 size 40.00GiB used 37.82GiB path /dev/sda2
On Mon, Oct 15, 2018 at 02:26:41PM +, Hugo Mills wrote:
> On Mon, Oct 15, 2018 at 05:24:08PM +0300, Anton Shepelev wrote:
> > Hello, all
> >
> > While trying to resolve free space problems, and found that
> > I cannot interpret the output of:
> >
> > > btrfs filesystem show
> >
> > Label:
On 2018-10-15 10:42, Anton Shepelev wrote:
Hugo Mills to Anton Shepelev:
While trying to resolve free space problems, and found
that I cannot interpret the output of:
btrfs filesystem show
Label: none uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
Total devices 1 FS bytes used
On Mon, Oct 15, 2018 at 05:24:08PM +0300, Anton Shepelev wrote:
> Hello, all
>
> While trying to resolve free space problems, and found that
> I cannot interpret the output of:
>
> > btrfs filesystem show
>
> Label: none uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
> Total devices 1 FS
Hugo Mills to Anton Shepelev:
>>While trying to resolve free space problems, and found
>>that I cannot interpret the output of:
>>
>>> btrfs filesystem show
>>
>>Label: none uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
>>Total devices 1 FS bytes used 34.06GiB
>>devid1 size
On Mon, Oct 15, 2018 at 05:40:40PM +0300, Anton Shepelev wrote:
> Hugo Mills to Anton Shepelev:
>
> >>While trying to resolve free space problems, and found
> >>that I cannot interpret the output of:
> >>
> >>> btrfs filesystem show
> >>
> >>Label: none uuid: 8971ce5b-71d9-4e46-ab25-ca37485784c8
Hello, all
How can I track down the origin of this mount point:
/dev/sda2 on /home/hana type btrfs
(rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot/hana)
if it is not present in /etc/fstab? I shouldn't like to
find/grep thoughout the whole filesystem.
--
() ascii
Hugo Mills - 15.10.18, 16:26:
> On Mon, Oct 15, 2018 at 05:24:08PM +0300, Anton Shepelev wrote:
> > Hello, all
> >
> > While trying to resolve free space problems, and found that
> >
> > I cannot interpret the output of:
> > > btrfs filesystem show
> >
> > Label: none uuid:
24 matches
Mail list logo
