Hi there,
BTFS is oopsing on me again ;-)
# uname -r
3.17.4-300.fc21.x86_64
Déc. 04 08:51:28 vajra kernel: [ cut here ]
déc. 04 08:51:28 vajra kernel: WARNING: CPU: 2 PID: 758 at fs/btrfs/delayed-
inode.c:1410 btrfs_assert_delayed_root_empty+0x39/0x40 [btrfs]()
déc. 04 0
Original Message
Subject: Re: Crazy idea of cleanup the inode_record btrfsck things with SQL?
From: Robert White
To: Qu Wenruo , linux-btrfs
Date: 2014年12月04日 03:18
On 12/01/2014 05:17 PM, Qu Wenruo wrote:
But I am also somewhat tired of bringing new structure new searchin
Phillip Susi posted on Wed, 03 Dec 2014 22:09:29 -0500 as excerpted:
> Are you sure the kernel only gains awareness of btrfs volumes when user
> space runs btrfs device scan? If that is so then that means you can not
> boot from a multi device btrfs root without using an initramfs. I
> thought t
Sandy McArthur Jr posted on Wed, 03 Dec 2014 20:20:38 -0500 as excerpted:
> mcplex src # btrfs-find-root /dev/sdh1
> Super think's the tree root is at 18948425080832, chunk root 22179840
> Well block 31789056 seems great, but generation doesn't match,
> have=720011, want=720141 level 0
> [many li
Hi David,
(2014/12/04 4:12), David Sterba wrote:
On Wed, Dec 03, 2014 at 09:11:48AM +0900, Satoru Takeuchi wrote:
It's not a Btrfs itself's feature. It's a snapper's feature.
It works as a helper of snapshot management.
1. You takes /snap by "snapper create" command.
2. You delete /snap by "sn
Original Message
Subject: If btrfs-find-root doesn't find tree roots is the filesystem lost?
From: Sandy McArthur Jr
To: linux-btrfs@vger.kernel.org
Date: 2014年12月04日 09:20
I have a many-disk btrfs filesystem that I cannot access after a
crash. When I run btrfs-find-root I ge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/03/2014 03:24 AM, Goffredo Baroncelli wrote:
> I am thinking about that. Today the device discovery happens: a)
> when a device appears, two udev rules run "btrfs dev scan
> "
>
> /lib/udev/rules.d/70-btrfs.rules
> /lib/udev/rules.d/80-btrfs-
When a leaf/node is corrupted in fs root, btrfsck will only complain
like "Check tree block failed, wanted=XXX, have=XXX" and skip wrong
leaf.
Such case will cause a lot of err, one of these err will mainly be
I_ERR_NO_INODE_ITEM.
This patchset will info user which leaf of the tree is corrupted an
Current btrfsck can skip corrupted leaf and even repair some corrupted
one if their bytenr or key order is wrong.
However when it comes to csum error leaf, btrfsck can only skip them,
which is OK for read-only iteration, but is bad for write.
This patch introduce the new repair_btree() function t
When leaf/node is corrupted in fs/subvolume root, btrfsck can ignore it
without much pain except some stderr messages complaining about it.
But this works fine doing read-only works, if we want to do deeper
recovery like rebuild missing inodes in the b+tree, it will cause
problem.
At least, info u
Add a basic inode item rebuild function for I_ERR_NO_INODE_ITEM.
The main use case is to repair btrfs which fs root has corrupted leaf,
but it is already working for case if the corrupteed fs root leaf/node
contains no inode extent_data.
The repair needs 3 elements for inode rebuild:
1. inode numb
On 01/12/2014 01:43, Goffredo Baroncelli wrote:
Hi all,
this patch provides a "mount.btrfs" helper for the mount command.
A btrfs filesystem could span several disks. This helper scans all the
partitions to discover all the disks required to mount a filesystem.
So it would not necessary any-mo
I have a many-disk btrfs filesystem that I cannot access after a
crash. When I run btrfs-find-root I get lots of "Well block [#] seems
great [...]" lines but zero "Generation: [...]" lines.
Is this filesystem lost?
Context info below. I'll upgrade to a 3.17.4 kernel soon and try again
just in cas
On Wed, Dec 03, 2014 at 07:26:33PM +0100, David Sterba wrote:
> On Tue, Dec 02, 2014 at 02:09:45PM +, Hugo Mills wrote:
> > On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
> > > On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote:
> > > > > export BTRFS_SUBVOLUME_DELETE_C
On Wed, Dec 03, 2014 at 07:48:43PM +0100, David Sterba wrote:
> On Tue, Dec 02, 2014 at 10:25:55AM -0500, Zygo Blaxell wrote:
> > On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
> > > > On a side note...only root can delete subvolumes, but non-root users
> > > > can create them, which
On 12/01/2014 05:17 PM, Qu Wenruo wrote:
But I am also somewhat tired of bringing new structure new searching
functions or even bring larger change on
the btrfsck record infrastructure when I found that can't provide the
function when new recovery function is going
to be implemented.
DISCLAIMER
On Wed, Dec 03, 2014 at 08:05:08AM +0530, Shriramana Sharma wrote:
> On Wed, Dec 3, 2014 at 5:41 AM, Satoru Takeuchi
> wrote:
> > 2. You delete /snap by "snapper delete" command by mistake.
> >Then snapper takes a "pre" snapshot just before deleting
> >/snap.
> > 3. Now /snap is deleted, h
On Wed, Dec 03, 2014 at 09:11:48AM +0900, Satoru Takeuchi wrote:
> It's not a Btrfs itself's feature. It's a snapper's feature.
> It works as a helper of snapshot management.
>
> 1. You takes /snap by "snapper create" command.
> 2. You delete /snap by "snapper delete" command by mistake.
> The
On Tue, Dec 02, 2014 at 04:11:54PM +0900, Satoru Takeuchi wrote:
> Hi,
>
> (2014/11/30 12:33), Shriramana Sharma wrote:
> > IIUC with BtrFS while it is possible to easily undelete a file or
> > ordinary directory if a snapshot of the containing subvol exists, it
> > seems that it's not elementary
On Tue, Dec 02, 2014 at 08:45:10PM +0530, Shriramana Sharma wrote:
> On Tue, Dec 2, 2014 at 6:26 PM, David Sterba wrote:
> >
> > Works for me without the root password on a Tumbleweed installation
> > (without apparmor/selinux).
>
> Are you then referring to a btrfs partition mounted with
> user
On Tue, Dec 02, 2014 at 10:25:55AM -0500, Zygo Blaxell wrote:
> On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
> > > On a side note...only root can delete subvolumes, but non-root users
> > > can create them, which results in...this:
> > >
> > > $ /sbin/btrfs sub create foo
> > >
Steps to reproduce:
# mkfs.btrfs -f /dev/sdb
# mount -t btrfs /dev/sdb /mnt
# btrfs sub create /mnt/dir
# mount -t btrfs /dev/sdb /mnt -o subvol=dir,subvol=dir
It fails with:
mount: mount(2) failed: No such file or directory
Btrfs deal with subvolume mounting in a recursive way,
to avoid loo
On Tue, Dec 02, 2014 at 02:09:45PM +, Hugo Mills wrote:
> On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote:
> > On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote:
> > > > export BTRFS_SUBVOLUME_DELETE_CONFIRM=1
> > > >
> > > > Ideas?
> > >
> > > Never rely on aliasing o
Hi,
Looks like
Reported-by: Daniel Miranda
also needs to be added see: "Re: Apparent metadata corruption (file that
simultaneously does/does not exist) on kernel 3.17.3"
Where Daniel reports these patches fixed his fs too.
I expect an fsck with --repair specified to change my fs and creat
Hello again,
Sorry for the delay, I had some things to do this past week, including
figuring out the stability problems that I was having, but everything
is good now. I rebuilt the Fedora package for btrfs-progs 3.17.2 with
your patches, and btrfsck successfully removed the orphan file! The
conten
On Wed, Dec 3, 2014 at 7:23 AM, Liu Bo wrote:
> On Tue, Dec 02, 2014 at 06:07:30PM +, Filipe Manana wrote:
>> On chunk allocation error (label "error_del_extent"), after adding the
>> extent map to the tree and to the pending chunks list, we would leave
>> decrementing the extent map's refcoun
On Wed, Dec 03, 2014 at 08:02:31AM +0530, Shriramana Sharma wrote:
> On Tue, Dec 2, 2014 at 2:04 PM, Hugo Mills wrote:
> >
> >> Is that correct: what btr sub list shows as "top level" is indeed the
> >> parent subvolume?
> >
> >No, it's the top-level subvolume. (See my earlier mail about
> > n
On 12/02/2014 08:11 PM, Phillip Susi wrote:
> On 12/2/2014 7:23 AM, Austin S Hemmelgarn wrote:
>> Stupid thought, why don't we just add blacklisting based on device
>> path like LVM has for pvscan?
>
> That isn't logic that belongs in the kernel, so that is going down the
> path of yanking out the
28 matches
Mail list logo
