Re: [PATCH] btrfs: handle dynamically reappearing missing device

On 11/17/2017 03:08 AM, Nikolay Borisov wrote: On 12.11.2017 12:56, Anand Jain wrote: If the device is not present at the time of (-o degrade) mount the mount context will create a dummy missing struct btrfs_device. Later this device may reappear after the FS is mounted. So this patch

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

Here's the whole output: gargamel:~# btrfs-debug-tree -t 258 /dev/mapper/raid0d1 | grep 1919805647 location key (1919805647 INODE_ITEM 0) type FILE item 30 key (1919805647 INODE_ITEM 0) itemoff 14415 itemsize 160 item 31 key (1919805647 INODE_REF 1919785864) itemoff

[PATCH] btrfs: extent-tree: Make btrfs_inode_rsv_refill function static

This function is no longer used outside of extent-tree.c. Make it static. Signed-off-by: Qu Wenruo --- fs/btrfs/extent-tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 673ac4e01dd0..309a109069f1

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

On Fri, Nov 17, 2017 at 01:17:19PM +0800, Qu Wenruo wrote: > > > On 2017年11月17日 10:26, Marc MERLIN wrote: > > Howdy, > > > > Up to date git pull from btrfs-progs: > > > > gargamel:~# btrfs check --repair /dev/mapper/raid0d1 > > enabling repair mode > > Checking filesystem on

Re: 4.13.12: kernel BUG at fs/btrfs/ctree.h:1802!

On Fri, Nov 17, 2017 at 10:41:48AM +0500, Roman Mamedov wrote: > On Thu, 16 Nov 2017 16:12:56 -0800 > Marc MERLIN wrote: > > > On Thu, Nov 16, 2017 at 11:32:33PM +0100, Holger Hoffstätte wrote: > > > Don't pop the champagne just yet, I just read that apprently 4.14 broke > > >

Re: btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

On 2017年11月17日 10:26, Marc MERLIN wrote: > Howdy, > > Up to date git pull from btrfs-progs: > > gargamel:~# btrfs check --repair /dev/mapper/raid0d1 > enabling repair mode > Checking filesystem on /dev/mapper/raid0d1 > UUID: 01334b81-c0db-4e80-92e4-cac4da867651 > checking extents > corrupt

Re: 4.13.12: kernel BUG at fs/btrfs/ctree.h:1802!

On Thu, 16 Nov 2017 16:12:56 -0800 Marc MERLIN wrote: > On Thu, Nov 16, 2017 at 11:32:33PM +0100, Holger Hoffstätte wrote: > > Don't pop the champagne just yet, I just read that apprently 4.14 broke > > bcache for some people [1]. Not sure how much that affects you, but it

Re: Btrfs restore error

On 2017年11月17日 11:56, Jay wrote: > Hello, > > I thought I should report something since there was little information > on this error. The situation is I have 2 external hard drives on > Xubuntu. One is not working and I need to move the data over to the > other. "btrfs replace" should be your

Btrfs restore error

Hello, I thought I should report something since there was little information on this error. The situation is I have 2 external hard drives on Xubuntu. One is not working and I need to move the data over to the other. I used 'sudo btrfs restore -v /dev/sde1 /mnt/Old4TB' and received 'Error

Re: Need help with incremental backup strategy (snapshots, defragmentingt & performance)

16.11.2017 19:13, Kai Krakow пишет: ... > > BTW: From user API perspective, btrfs snapshots do not guarantee > perfect granular consistent backups. Is it documented somewhere? I was relying on crash-consistent write-order-preserving snapshots in NetApp for as long as I remember. And I was sure

btrfs check: add_missing_dir_index: BUG_ON `ret` triggered, value -17

Howdy, Up to date git pull from btrfs-progs: gargamel:~# btrfs check --repair /dev/mapper/raid0d1 enabling repair mode Checking filesystem on /dev/mapper/raid0d1 UUID: 01334b81-c0db-4e80-92e4-cac4da867651 checking extents corrupt extent record: key 203003699200 168 40960 corrupt extent record:

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On Thu, Nov 16, 2017 at 6:54 PM, Chris Murphy wrote: > The user doesn't have to setup dm-verity to get this. Or dm-integrity, rather. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On Thu, Nov 16, 2017 at 6:22 PM, Qu Wenruo wrote: > > > On 2017年11月17日 06:32, Chris Murphy wrote: > >> It's good the file system can stay alive, but data is the much >> bigger target in terms of percent space on the physical media, > > It's also true. > (Although working

Re: 4.13.12: kernel BUG at fs/btrfs/ctree.h:1802!

On Thu, Nov 16, 2017 at 01:45:51PM -0800, Marc MERLIN wrote: > On Thu, Nov 16, 2017 at 06:27:44PM +0100, Holger Hoffstätte wrote: > > On 11/16/17 18:07, Marc MERLIN wrote: > > > Sorry, was missing the kernel number in the subject, just fixed that. > > > > > > On Thu, Nov 16, 2017 at 09:04:45AM

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On 2017年11月17日 00:47, Austin S. Hemmelgarn wrote: >> >> This is at least less complicated than dm-integrity. >> >> Just a new hook for READ bio. And it can start from easy part. >> Like starting from dm-raid1 and other fs support. > It's less complicated for end users (in theory, but cryptsetup

Re: [PATCH 10/10] btrfs: rework end io for extent buffer reads

On Tue, Nov 14, 2017 at 04:56:56PM -0500, Josef Bacik wrote: > From: Josef Bacik > > Now that the only thing that keeps eb's alive is io_pages and it's > refcount we need to hold the eb ref for the entire end io call so we > don't get it removed out from underneath us. Also the

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On 2017年11月17日 06:32, Chris Murphy wrote: > On Thu, Nov 16, 2017 at 3:04 AM, Qu Wenruo wrote: > >> For example, if we use the following device mapper layout: >> >> FS (can be any fs with metadata csum) >> | >> dm-integrity >>

Re: [PATCH 09/10] Btrfs: kill the btree_inode

On Thu, Nov 16, 2017 at 05:03:08PM -0800, Liu Bo wrote: > On Tue, Nov 14, 2017 at 04:56:55PM -0500, Josef Bacik wrote: > > From: Josef Bacik > > > > In order to more efficiently support sub-page blocksizes we need to stop > > allocating pages from pagecache for our metadata.

Re: [PATCH 09/10] Btrfs: kill the btree_inode

On Tue, Nov 14, 2017 at 04:56:55PM -0500, Josef Bacik wrote: > From: Josef Bacik > > In order to more efficiently support sub-page blocksizes we need to stop > allocating pages from pagecache for our metadata. Instead switch to using the > account_metadata* counters for making

Re: 4.13.12: kernel BUG at fs/btrfs/ctree.h:1802!

On Thu, Nov 16, 2017 at 11:32:33PM +0100, Holger Hoffstätte wrote: > Don't pop the champagne just yet, I just read that apprently 4.14 broke > bcache for some people [1]. Not sure how much that affects you, but it might > well make things worse. Yeah, I know, wonderful. Oh my, that's actually

Re: [PATCH 02/10] writeback: convert WB_WRITTEN/WB_DIRITED counters to bytes

On Tue, Nov 14, 2017 at 04:56:48PM -0500, Josef Bacik wrote: > From: Josef Bacik > > These are counters that constantly go up in order to do bandwidth > calculations. > It isn't important what the units are in, as long as they are consistent > between > the two of them, so

Re: [PATCH 01/10] remove mapping from balance_dirty_pages*()

On Tue, Nov 14, 2017 at 04:56:47PM -0500, Josef Bacik wrote: > From: Josef Bacik > > The only reason we pass in the mapping is to get the inode in order to see if > writeback cgroups is enabled, and even then it only checks the bdi and a super > block flag. balance_dirty_pages()

Re: [PATCH 6/6] btrfs: reoder btrfs_transaction members for better packing

On Wed, Nov 15, 2017 at 06:42:06PM +0100, David Sterba wrote: > There are now 20 bytes of holes, we can reduce that to 4 by minor > changes. Moving 'aborted' to the status and flags is also more logical, > similar for num_dirty_bgs. The size goes from 432 to 416. > Reviewed-by: Liu Bo

Re: [PATCH] btrfs: handle dynamically reappearing missing device

On Sun, Nov 12, 2017 at 06:56:50PM +0800, Anand Jain wrote: > If the device is not present at the time of (-o degrade) mount > the mount context will create a dummy missing struct btrfs_device. > Later this device may reappear after the FS is mounted. This commit log doesn't explain what would

Re: 4.13.12: kernel BUG at fs/btrfs/ctree.h:1802!

On 11/16/17 22:45, Marc MERLIN wrote: (snip) >> This BUG() was recently removed and seems to be caused by some kind >> of persistent corruption, which is seen as invalid inline extent. >> See [1], [2] for details. Maybe you can backport them? >> Alternatively just give 4.14 a whirl, it's great. >>

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On Thu, Nov 16, 2017 at 3:04 AM, Qu Wenruo wrote: > For example, if we use the following device mapper layout: > > FS (can be any fs with metadata csum) > | > dm-integrity > | > dm-raid1 >/

Re: [PATCH v2 1/3] btrfs: tree-checker: Fix false panic for sanity test

On Wed, Nov 08, 2017 at 08:54:24AM +0800, Qu Wenruo wrote: > [BUG] > If we run btrfs with CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y, it will > instantly cause kernel panic like: > > -- > ... > assertion failed: 0, file: fs/btrfs/disk-io.c, line: 3853 > ... > Call Trace: >

Re: 4.13.12: kernel BUG at fs/btrfs/ctree.h:1802!

On Thu, Nov 16, 2017 at 06:27:44PM +0100, Holger Hoffstätte wrote: > On 11/16/17 18:07, Marc MERLIN wrote: > > Sorry, was missing the kernel number in the subject, just fixed that. > > > > On Thu, Nov 16, 2017 at 09:04:45AM -0800, Marc MERLIN wrote: > >> My server now reboots every 20mn or so,

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On Thu, Nov 16, 2017 at 11:47:45AM -0500, Austin S. Hemmelgarn wrote: > > > >At least btrfs can take the advantage of the simplicity of separate layers. > > > >And other filesystem can get a little higher chance to recover its > >metadata if built on dm-raid. > Again, just put dm-integrity below

Re: zstd compression

2017-11-16 19:32 GMT+03:00 Austin S. Hemmelgarn : > On 2017-11-16 08:43, Duncan wrote: >> >> Austin S. Hemmelgarn posted on Thu, 16 Nov 2017 07:30:47 -0500 as >> excerpted: >> >>> On 2017-11-15 16:31, Duncan wrote: Austin S. Hemmelgarn posted on Wed, 15 Nov 2017

Re: [PATCH] btrfs: handle dynamically reappearing missing device

On 12.11.2017 12:56, Anand Jain wrote: > If the device is not present at the time of (-o degrade) mount > the mount context will create a dummy missing struct btrfs_device. > Later this device may reappear after the FS is mounted. So this > patch handles that case by going through the

Re: 4.13.12: kernel BUG at fs/btrfs/ctree.h:1802!

On 11/16/17 18:07, Marc MERLIN wrote: > Sorry, was missing the kernel number in the subject, just fixed that. > > On Thu, Nov 16, 2017 at 09:04:45AM -0800, Marc MERLIN wrote: >> My server now reboots every 20mn or so, with this. >> Sadly another BUG_ON() and it won't even tell me which filesystem

4.13.12: kernel BUG at fs/btrfs/ctree.h:1802!

Sorry, was missing the kernel number in the subject, just fixed that. On Thu, Nov 16, 2017 at 09:04:45AM -0800, Marc MERLIN wrote: > My server now reboots every 20mn or so, with this. > Sadly another BUG_ON() and it won't even tell me which filesystem > it's on > > static inline u32

kernel BUG at fs/btrfs/ctree.h:1802!

My server now reboots every 20mn or so, with this. Sadly another BUG_ON() and it won't even tell me which filesystem it's on static inline u32 btrfs_extent_inline_ref_size(int type) { if (type == BTRFS_TREE_BLOCK_REF_KEY || type == BTRFS_SHARED_BLOCK_REF_KEY)

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On 2017-11-16 09:06, Qu Wenruo wrote: On 2017年11月16日 20:33, Zdenek Kabelac wrote: Dne 16.11.2017 v 11:04 Qu Wenruo napsal(a): On 2017年11月16日 17:43, Zdenek Kabelac wrote: Dne 16.11.2017 v 09:08 Qu Wenruo napsal(a): [What we have] The nearest infrastructure I found in kernel is

Re: Tiered storage?

Am Wed, 15 Nov 2017 08:11:04 +0100 schrieb waxhead : > As for dedupe there is (to my knowledge) nothing fully automatic yet. > You have to run a program to scan your filesystem but all the > deduplication is done in the kernel. > duperemove works apparently quite well

[josef-btrfs:slab-priority 1/1] mm/vmscan.c:336:2: error: 'deleta' undeclared

tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git slab-priority head: c5c56bb8db68a328b5e55cab87b5e6306177e9b2 commit: c5c56bb8db68a328b5e55cab87b5e6306177e9b2 [1/1] mm: use sc->priority for slab shrink targets config: i386-randconfig-x001-201746 (attached as

[josef-btrfs:slab-priority 1/1] vmscan.c:undefined reference to `__udivdi3'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git slab-priority head: bd319083ec02fd19b9f3522935d3c6c0528e1864 commit: bd319083ec02fd19b9f3522935d3c6c0528e1864 [1/1] mm: use sc->priority for slab shrink targets config: i386-tinyconfig (attached as .config) compiler:

Re: zstd compression

On 2017-11-16 08:43, Duncan wrote: Austin S. Hemmelgarn posted on Thu, 16 Nov 2017 07:30:47 -0500 as excerpted: On 2017-11-15 16:31, Duncan wrote: Austin S. Hemmelgarn posted on Wed, 15 Nov 2017 07:57:06 -0500 as excerpted: The 'compress' and 'compress-force' mount options only impact newly

Re: Need help with incremental backup strategy (snapshots, defragmentingt & performance)

Link 2 slipped away, adding it below... Am Tue, 14 Nov 2017 15:51:57 -0500 schrieb Dave : > On Tue, Nov 14, 2017 at 3:50 AM, Roman Mamedov wrote: > > > > On Mon, 13 Nov 2017 22:39:44 -0500 > > Dave wrote: > > > > > I have my

Re: Need help with incremental backup strategy (snapshots, defragmentingt & performance)

Am Tue, 14 Nov 2017 15:51:57 -0500 schrieb Dave : > On Tue, Nov 14, 2017 at 3:50 AM, Roman Mamedov wrote: > > > > On Mon, 13 Nov 2017 22:39:44 -0500 > > Dave wrote: > > > > > I have my live system on one block device and a

Re: Read before you deploy btrfs + zstd

On Wed, 15 Nov 2017 20:23:44 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Tho from my understanding and last I read, btrfs restore (I believe > it was) hadn't been updated to handle zstd yet, tho btrfs check and > btrfs filesystem defrag had been, and of course btrfs balance if the > kernel

Re: [PATCH 2/2] btrfs: introduce feature to ignore a btrfs device

On 13.11.2017 07:44, Anand Jain wrote: > Support for a new command is being added here: > btrfs dev ignore > Which shall undo the effects of the command > btrfs dev scan > > This cli/ioctl is needed as there is no way to continue to mount in > degraded mode if the device is already scanned,

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On 2017年11月16日 20:33, Zdenek Kabelac wrote: > Dne 16.11.2017 v 11:04 Qu Wenruo napsal(a): >> >> >> On 2017年11月16日 17:43, Zdenek Kabelac wrote: >>> Dne 16.11.2017 v 09:08 Qu Wenruo napsal(a): > [What we have] The nearest infrastructure I found in kernel is

Re: [PATCH 2/2] btrfs: introduce feature to ignore a btrfs device

On 13.11.2017 07:44, Anand Jain wrote: > Support for a new command is being added here: > btrfs dev ignore > Which shall undo the effects of the command > btrfs dev scan > > This cli/ioctl is needed as there is no way to continue to mount in > degraded mode if the device is already scanned,

Re: [PATCH 1/2] btrfs: refactor btrfs_free_stale_device() to get device list delete

On 13.11.2017 07:44, Anand Jain wrote: > We need to delete a device from the dev_list, so refactor > btrfs_free_stale_device() for delete_device_from_list(). > > Signed-off-by: Anand Jain > --- > fs/btrfs/volumes.c | 27 +-- > 1 file changed, 17

Re: [PATCH] btrfs: fix deadlock when writing out space cache

On 16.11.2017 15:50, Chris Mason wrote: > > > On 11/16/2017 03:09 AM, Nikolay Borisov wrote: >> >> >> On 15.11.2017 23:20, Josef Bacik wrote: >>> From: Josef Bacik >>> >>> If we fail to prepare our pages for whatever reason (out of memory in >>> our case) we need to make sure

Re: [PATCH] btrfs: fix deadlock when writing out space cache

On 11/16/2017 03:09 AM, Nikolay Borisov wrote: On 15.11.2017 23:20, Josef Bacik wrote: From: Josef Bacik If we fail to prepare our pages for whatever reason (out of memory in our case) we need to make sure to drop the block_group->data_rwsem, otherwise hilarity ensues.

Re: zstd compression

Austin S. Hemmelgarn posted on Thu, 16 Nov 2017 07:30:47 -0500 as excerpted: > On 2017-11-15 16:31, Duncan wrote: >> Austin S. Hemmelgarn posted on Wed, 15 Nov 2017 07:57:06 -0500 as >> excerpted: >> >>> The 'compress' and 'compress-force' mount options only impact newly >>> written data. The

Re: zstd compression

On 11/16/17, Austin S. Hemmelgarn wrote: > I'm pretty sure defrag is equivalent to 'compress-force', not > 'compress', but I may be wrong. Are there any devs to confirm this? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On 2017-11-16 07:33, Zdenek Kabelac wrote: Dne 16.11.2017 v 11:04 Qu Wenruo napsal(a): On 2017年11月16日 17:43, Zdenek Kabelac wrote: Dne 16.11.2017 v 09:08 Qu Wenruo napsal(a): [What we have] The nearest infrastructure I found in kernel is bio_integrity_payload. Hi We already have 

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

Dne 16.11.2017 v 11:04 Qu Wenruo napsal(a): On 2017年11月16日 17:43, Zdenek Kabelac wrote: Dne 16.11.2017 v 09:08 Qu Wenruo napsal(a): [What we have] The nearest infrastructure I found in kernel is bio_integrity_payload. Hi We already have  dm-integrity target upstream. What's missing

Re: zstd compression

On 2017-11-15 16:31, Duncan wrote: Austin S. Hemmelgarn posted on Wed, 15 Nov 2017 07:57:06 -0500 as excerpted: The 'compress' and 'compress-force' mount options only impact newly written data. The compression used is stored with the metadata for the extents themselves, so any existing data

КЛИЕНТСКИЕ БАЗЫ!!! Подробнее: prodawez...@gmail.com Узнайте подробности!

KLIENTSKIE BAZI!!! Podrobnee: prodawez...@gmail.com Uznaite podrobnosti! -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On 2017年11月16日 17:43, Zdenek Kabelac wrote: > Dne 16.11.2017 v 09:08 Qu Wenruo napsal(a): >> >> >>> >> [What we have] >> The nearest infrastructure I found in kernel is >> bio_integrity_payload. >> > > Hi > > We already have  dm-integrity target upstream. > What's missing

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

Dne 16.11.2017 v 09:08 Qu Wenruo napsal(a): [What we have] The nearest infrastructure I found in kernel is bio_integrity_payload. Hi We already have dm-integrity target upstream. What's missing in this target ? Regards Zdenek -- To unsubscribe from this list: send the line

Re: [PATCH v2] fstests: btrfs/143: make test case more reliable

On 16.11.2017 01:47, Liu Bo wrote: > This changes to use '_scratch_cycle_mount' to drop all caches btrfs could have > in order to avoid an issue that drop_caches somehow doesn't work on Nikolay's > box. > > Also use bash -c to run 'read' only when %pid is odd so that we can read the > faulty

Re: [PATCH] btrfs: fix deadlock when writing out space cache

On 15.11.2017 23:20, Josef Bacik wrote: > From: Josef Bacik > > If we fail to prepare our pages for whatever reason (out of memory in > our case) we need to make sure to drop the block_group->data_rwsem, > otherwise hilarity ensues. > > Signed-off-by: Josef Bacik

Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

On 2017年11月16日 15:42, Nikolay Borisov wrote: > > > On 16.11.2017 09:38, Qu Wenruo wrote: >> >> >> On 2017年11月16日 14:54, Nikolay Borisov wrote: >>> >>> >>> On 16.11.2017 04:18, Qu Wenruo wrote: Hi all, [Background] Recently I'm considering the possibility to use checksum