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 device
On Wed, Dec 03, 2014 at 08:02:31AM +0530, Shriramana Sharma wrote:
On Tue, Dec 2, 2014 at 2:04 PM, Hugo Mills h...@carfax.org.uk 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
On Wed, Dec 3, 2014 at 7:23 AM, Liu Bo bo.li@oracle.com 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
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
Hi,
Looks like
Reported-by: Daniel Miranda danielk...@gmail.com
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
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 or environment
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
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
Create
On Tue, Dec 02, 2014 at 08:45:10PM +0530, Shriramana Sharma wrote:
On Tue, Dec 2, 2014 at 6:26 PM, David Sterba dste...@suse.cz 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
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 to
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.
Then snapper
On Wed, Dec 03, 2014 at 08:05:08AM +0530, Shriramana Sharma wrote:
On Wed, Dec 3, 2014 at 5:41 AM, Satoru Takeuchi
takeuchi_sat...@jp.fujitsu.com wrote:
2. You delete /snap by snapper delete command by mistake.
Then snapper takes a pre snapshot just before deleting
/snap.
3. Now
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.
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 results
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_CONFIRM=1
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 case.
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
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
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
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 and
-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
device
/lib/udev/rules.d/70-btrfs.rules
Original Message
Subject: If btrfs-find-root doesn't find tree roots is the filesystem lost?
From: Sandy McArthur Jr sandy...@gmail.com
To: linux-btrfs@vger.kernel.org linux-btrfs@vger.kernel.org
Date: 2014年12月04日 09:20
I have a many-disk btrfs filesystem that I cannot access
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
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 lines
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 the
Original Message
Subject: Re: Crazy idea of cleanup the inode_record btrfsck things with SQL?
From: Robert White rwh...@pobox.com
To: Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs
linux-btrfs@vger.kernel.org
Date: 2014年12月04日 03:18
On 12/01/2014 05:17 PM, Qu Wenruo wrote:
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
27 matches
Mail list logo
