From: Anand Jain
The cli 'btrfs inspect dump-tree ' will scan for the partner devices
if any by default.
So as of now you can not inspect each mirrored device independently.
This patch adds noscan option, which when used won't scan the system for
the partner devices, instead it just uses the de
On Wed, Apr 03, 2019 at 08:09:03PM +0200, Christoph Hellwig wrote:
> On Fri, Mar 29, 2019 at 11:26:43PM +0300, Andy Shevchenko wrote:
> > When the ID comes from or we would like to pass it to a raw buffer,
> > the casting is needed.
>
> Something is missing in this sentence.
What I meant there is
For some time, I've been running a log bot on the #btrfs IRC
channel, and hosting the resulting logs. I'm currently re-assessing
the collection of things I host and manage. Baudot, the "official"
#btrfs log bot, has never really been stable, and is very sensitive to
being disconnected from the I
On 4/4/19 1:45 PM, Hugo Mills wrote:
>For some time, I've been running a log bot on the #btrfs IRC
> channel, and hosting the resulting logs. I'm currently re-assessing
> the collection of things I host and manage. Baudot, the "official"
> #btrfs log bot, has never really been stable, and is ve
On Thu, Apr 04, 2019 at 09:23:11AM +0300, Nikolay Borisov wrote:
>
>
> On 4.04.19 г. 6:47 ч., Qu Wenruo wrote:
> > Commit 1ba98d086fe3 ("Btrfs: detect corruption when non-root leaf has
> > zero item") introduced comprehensive root owner checker.
> >
> > However it's pretty expensive tree search
2019-04-03 03:04, Qu Wenruo:
[snip]
...
In your case, you just need latest btrfs-progs and re-run "btrfs check
--readonly" on it.
Will try this, but have no time before tomorrow evening.
If it just shows the same result, meaning I can't get the info about
which tree block is corrupte
2019-04-04 04:48, Jeff Mahoney:
On 3/31/19 2:44 PM, bt...@avgustinov.eu wrote:
Dear all,
I am a big fan of btrfs, and I am using it since 2013 - in the meantime
on at least four different computers. During this time, I suffered at
least four bad btrfs-failures leading to unmountable, unreada
From: Filipe Manana
Currently the fsync function can only be performed against regular files.
Allow it to operate on directories too, to increase test coverage and
allow for chances of finding bugs in a filesystem's implementation of
fsync against directories.
Signed-off-by: Filipe Manana
---
From: Filipe Manana
The previous patches added support for operations to set and get xattrs on
regular files and directories, this patch just adds one operation to delete
xattrs on files and directories.
Signed-off-by: Filipe Manana
---
V2: Use a different name for the operation (delfattr) and
From: Filipe Manana
Currently fsstress does not exercise creating, reading or deleting xattrs
on files or directories. This change adds support for setting xattrs on
files and directories, using only the xattr user namespace (the other
namespaces are not general purpose and are used for security,
From: Filipe Manana
Currently the afsync function can only be performed against regular files.
Allow it to operate on directories too, to increase test coverage and
allow for chances of finding bugs in a filesystem's implementation of
fsync against directories.
Signed-off-by: Filipe Manana
---
From: Filipe Manana
The previous patch added support for an operation to set xattrs on regular
files and directories, this patch just adds one operation to read (get)
them.
Signed-off-by: Filipe Manana
---
V2: Use a different name for the operation (getfattr) and make use of the
helper fun
From: Filipe Manana
The previous patches added support for operations to set, get and delete
xattrs on regular files and directories, this patch just adds an operation
to list the xattrs of a file/directory.
Signed-off-by: Filipe Manana
---
V2: New patch in the series, the first version of the
From: Filipe Manana
Currently fssum, mostly used for btrfs test cases that test the btrfs send
feature, ignores completely the existence of xattrs. This change teaches
fssum to find xattrs and make them contribute to the checksum of a
filesystem, so that we can catch filesystem bugs regarding mis
On Thu, Apr 4, 2019 at 9:58 AM Nik. wrote:
>
>
> 2019-04-04 04:48, Jeff Mahoney:
> > On 3/31/19 2:44 PM, bt...@avgustinov.eu wrote:
> >> Dear all,
> >>
> >>
> >> I am a big fan of btrfs, and I am using it since 2013 - in the meantime
> >> on at least four different computers. During this time, I s
Yes, I have qgroups enabled on that filesystem. I'll disable qgroups
the next chance I get, they aren't worth the trouble.
After rebooting, BTRFS finished the balance. I then foolishly started
a selective metadata balance, which never got past the first block
group; it just thrashed the disk for
On Fri, Mar 29, 2019 at 08:21:47AM +1100, Dave Chinner wrote:
> On Thu, Mar 28, 2019 at 10:50:47AM -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 del
On 2019/4/4 下午11:27, Nik. wrote:
>
>
> 2019-04-03 03:04, Qu Wenruo:
>>
>
> [snip]
> ...
>
In your case, you just need latest btrfs-progs and re-run "btrfs check
--readonly" on it.
>>>
>>> Will try this, but have no time before tomorrow evening.
>>>
>>>
If it just shows the same
On Thu, Apr 4, 2019 at 12:18 PM Zirconium Hacker wrote:
>
> Yes, I have qgroups enabled on that filesystem. I'll disable qgroups
> the next chance I get, they aren't worth the trouble.
>
> After rebooting, BTRFS finished the balance. I then foolishly started
> a selective metadata balance, which
I've actually had a check running for the past 10 hours or so.
It got far enough, so I stopped it. The output is attached.
Opening filesystem to check...
Checking filesystem on /dev/sdh1
UUID: c73a1699-41e6-445f-82f1-116e6e46eb64
[1/7] checking root items
[2/7] checking extents
parent transid veri
Hi Chris,
Thanks for spending the time and energy to help me look into this.
btrfs restore isn't very happy either, so I guess I'll wait until
btrfs-progs v5.0 comes out and see if that helps.
btrfs restore says...
% ./btrfs restore -v -D /dev/sda1 /data2
This is a dry-run, no files are going to
On Thu, Apr 4, 2019 at 11:24 PM Zirconium Hacker wrote:
>
> I've actually had a check running for the past 10 hours or so.
> It got far enough, so I stopped it. The output is attached.
What do you get for:
# btrfs insp dump-s -f /dev/
# btrfs insp dump-t -b 2629033574400 /dev/
The csum test do
On Thu, Apr 4, 2019 at 11:51 PM Glenn Trigg wrote:
>
> Hi Chris,
>
> Thanks for spending the time and energy to help me look into this.
>
> btrfs restore isn't very happy either, so I guess I'll wait until
> btrfs-progs v5.0 comes out and see if that helps.
>
> btrfs restore says...
> % ./btrfs re
On Wed, Apr 3, 2019 at 8:48 PM Jeff Mahoney wrote:
>
> My team is always interested in images of broken file systems. This is
> how --repair evolves. Images with failed --repair operations are still
> valuable. That's the first step most users take and why wouldn't they?
> If --repair is misbe
2019-04-05 02:47, Qu Wenruo:
On 2019/4/4 下午11:27, Nik. wrote:
2019-04-03 03:04, Qu Wenruo:
[snip]
...
In your case, you just need latest btrfs-progs and re-run "btrfs check
--readonly" on it.
Will try this, but have no time before tomorrow evening.
If it just shows the same res
25 matches
Mail list logo
