On Friday, May 05, 2017 11:57:15 AM Josef Bacik wrote:
> Instead pass around the failure tree and the io tree.
>
The changes look fine,
Reviewed-by: Chandan Rajendra
--
chandan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.
On Friday, May 05, 2017 11:57:14 AM Josef Bacik wrote:
> Once we remove the btree_inode we won't have an inode to pass anymore, just
> pass
> the fs_info directly and the inum since we use that to print out the repair
> message.
>
The changes look fine,
Reviewed-by: Chandan Rajendra
--
chandan
On Friday, May 05, 2017 11:57:13 AM Josef Bacik wrote:
> For extent_io tree's we have carried the address_mapping of the inode around
> in
> the io tree in order to pull the inode back out for calling into various tree
> ops hooks. This works fine when everything that has an extent_io_tree has an
Ping?
Any comments?
Thanks,
Qu
At 03/30/2017 02:20 PM, Qu Wenruo wrote:
For any one who wants to try it, it can be get from my repo:
https://github.com/adam900710/btrfs-progs/tree/offline_scrub
Several reports on kernel scrub screwing up good data stripes are in ML
for sometime.
And since ke
Chris Murphy posted on Mon, 08 May 2017 13:26:16 -0600 as excerpted:
> On Sat, May 6, 2017 at 4:33 AM, Tom Hale wrote:
>> Below (and also attached because of formatting) is an example of `btrfs
>> scrub` incorrectly reporting that errors have been corrected.
>>
>> In this example, /dev/md127 is t
On Fri, May 05, 2017 at 09:45:30PM +0200, David Sterba wrote:
> On Wed, Apr 26, 2017 at 04:14:16AM +0200, Adam Borowski wrote:
> > On Wed, Apr 19, 2017 at 11:07:45PM +0200, Adam Borowski wrote:
> > > Too many people come complaining about losing their data -- and indeed,
> > > there's no warning ou
On 2017-01-28 13:15, MegaBrutal wrote:
Hello,
Of course I can't retrieve the data from before the balance, but here
is the data from now:
root@vmhost:~# btrfs fi show /tmp/mnt/curlybrace
Label: 'curlybrace' uuid: f471bfca-51c4-4e44-ac72-c6cd9ccaf535
Total devices 1 FS bytes used 752.38MiB
On Wed, May 03, 2017 at 06:08:36PM +0800, Eryu Guan wrote:
> On Fri, Apr 28, 2017 at 11:25:52AM -0600, Liu Bo wrote:
> > This case tests whether dio read can repair the bad copy if we have
> > a good copy.
> >
> > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks")
> > intro
On Mon, May 8, 2017 at 1:15 PM, Alexandru Guzu wrote:
> Also I was unable to find a way to send-receive a snapshot to the root
> subvolume of a different disk. Is this possible?
btrfs send /mnt/brick1/root.20170508 | btrfs receive /mnt/brick2
You need to snapshot it again to make it
On Sat, May 6, 2017 at 4:33 AM, Tom Hale wrote:
> Below (and also attached because of formatting) is an example of `btrfs
> scrub` incorrectly reporting that errors have been corrected.
>
> In this example, /dev/md127 is the device created by running:
> mdadm --build /dev/md0 --level=faulty --raid
My setup is a single disk, single btrfs subvolume (/) without a
separate boot partition.
I resolved the issue like this from a Live CD:
1 - take a (read-only) snapshot of the current problematic root system
and use send-receive to another BTRFS disk
2 - re-format the original partition as btrfs (m
On Mon, May 8, 2017 at 12:22 PM, Alexandru Guzu wrote:
> Getting a bit off-topic here, but were you able to boot from that fs
> with grub after a simple rsync?
I've done it with rsync as well as send/receive and both result in
bootable systems. I use rsync -pogAXtlHrDx because that's what
Fedora'
On Mon, May 8, 2017 at 8:16 AM, Alexandru Guzu wrote:
> Deleting the Firefox cache with the LiveCD resolved the issue where
> the FS would become read-only when opening Firefox, however, the
> lowmem check still reports errors. There are probably some other files
> that would cause the FS to becom
On Tue, May 02, 2017 at 03:37:15PM +0100, Filipe Manana wrote:
> On Fri, Apr 28, 2017 at 6:25 PM, Liu Bo wrote:
> > This case tests whether dio read can repair the bad copy if we have
> > a good copy.
> >
> > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks")
> > introduced
Hi Jeff,
On Fri, May 05, 2017 at 04:11:18PM -0400, Jeff Layton wrote:
> On Fri, 2017-05-05 at 12:21 -0700, Liu Bo wrote:
> > Hi Jeff,
> >
> > On Thu, May 04, 2017 at 07:26:17AM -0400, Jeff Layton wrote:
> > > I've been working on set of patches to clean up how writeback errors are
> > > tracked a
Getting a bit off-topic here, but were you able to boot from that fs
with grub after a simple rsync?
On Mon, May 8, 2017 at 1:01 PM, Sean Greenslade wrote:
> On Mon, May 08, 2017 at 12:41:11PM -0400, Austin S. Hemmelgarn wrote:
>> Send/receive is not likely to transfer the problem unless it has s
May be someone more talented will be able to assist you but in my
experience this kind of damage is fatal in practice (even if you could
theoretically fix it, it's probably easier to recreate the fs and
restore the content from backup, or use the rescue tool to save some
of the old content which yo
On Mon, May 08, 2017 at 12:41:11PM -0400, Austin S. Hemmelgarn wrote:
> Send/receive is not likely to transfer the problem unless it has something
> to do with how things are reflinked. Receive operates by recreating the
> sent subvolume from userspace using regular commands and the clone ioctls,
On 2017-05-08 12:22, Sean Greenslade wrote:
On May 8, 2017 11:28:42 AM EDT, Sanidhya Solanki wrote:
On Mon, 8 May 2017 10:16:44 -0400
Alexandru Guzu wrote:
Sean, how would you approach the copy of the data back and forth if
the OS is on it? Would a Send-receive and then back work?
You coul
On May 8, 2017 11:28:42 AM EDT, Sanidhya Solanki wrote:
>On Mon, 8 May 2017 10:16:44 -0400
>Alexandru Guzu wrote:
>
>> Sean, how would you approach the copy of the data back and forth if
>> the OS is on it? Would a Send-receive and then back work?
>
>You could use a Live-USB and then just dd it
On Mon, 8 May 2017 10:16:44 -0400
Alexandru Guzu wrote:
> Sean, how would you approach the copy of the data back and forth if
> the OS is on it? Would a Send-receive and then back work?
You could use a Live-USB and then just dd it to remote or attached storage, if
you want to be absolutely sure
Deleting the Firefox cache with the LiveCD resolved the issue where
the FS would become read-only when opening Firefox, however, the
lowmem check still reports errors. There are probably some other files
that would cause the FS to become read-only again, but I'm not sure
how to find them.
I took a
On 2017-05-05 19:03, Lewis Diamond wrote:
> Hi,
>
> I ran into a situation where my incremental backups using send|receive
> are failing after a full file system failure followed by restore from an
> external backup. The reason for the failures seem to be that the
> Received UUID of snapshots and
subscribe linux-btrfs
subscribe linux-btrfs
Btrfs header has a u64 member flags, whose lowest 56 bits are for header
flags like WRITTEN and RELOC.
And its highest 8 bits are for backref revision.
Manually checking btrfs_header_flags() will be a pain, so add such leaf
flags and backref revision output for print-tree.
Signed-off-by: Qu Wenru
26 matches
Mail list logo
