Documenting MS_LAZYTIME
Hello Ted, Based on your commit message 0ae45f63d4e, I I wrote the documentation below for MS_LAZYTIME, to go into the mount(2) man page. Could you please check it over and let me know if it's accurate. In particular, I added pieces marked with * below that were not part of the commit message and I'd like confirmation that they're accurate. Thanks, Michael [[ MS_LAZYTIME (since Linux 3.20) Only update filetimes (atime, mtime, ctime) on the in- memory version of the file inode. The on-disk time‐ stamps are updated only when: (a) the inode needs to be updated for some change unre‐ lated to file timestamps; (b) the application employs fsync(2), syncfs(2), or sync(2); (c) an undeleted inode is evicted from memory; or * (d) more than 24 hours have passed since the i-node was * written to disk. This mount option significantly reduces writes to the inode table for workloads that perform frequent random writes to preallocated files. * As at Linux 3.20, this option is supported only on ext4. ]] -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface, http://blog.man7.org/ -- 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: [GIT PULL] Btrfs
On 2015.02.19 at 15:36 -0500, Chris Mason wrote: Hi Linus, Please pull my for-linus branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus I get the following warnings during Firefox LTO build. lto1-wpa-stream outputs the final object files in parallel and therefore stresses the filessystem. These warnings started with the git merge above. The disk is a conventional drive: [2.438132] scsi 1:0:0:0: Direct-Access ATA ST2000DM001-1CH1 CC29 PQ: 0 ANSI: 5 [2.438308] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [2.438310] sd 1:0:0:0: [sda] 4096-byte physical blocks /dev/sda2 btrfs 1.9T 905G 946G 49% /var /dev/sda2 on /var type btrfs (rw,relatime,compress=lzo,noacl,space_cache) [ 4155.708579] [ cut here ] [ 4155.708590] WARNING: CPU: 1 PID: 8850 at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x278/0x2a0() [ 4155.708593] CPU: 1 PID: 8850 Comm: lto1-wpa-stream Not tainted 3.19.0-08975-g3d883483dc0a-dirty #101 [ 4155.708594] Hardware name: System manufacturer System Product Name/M4A78T-E, BIOS 350304/13/2011 [ 4155.708595] 81999aad 8168d303 [ 4155.708597] 8106d2d2 8800dad9bb78 88018554ccc0 880215e2e000 [ 4155.708599] 880215f23000 8121b6f8 [ 4155.708601] Call Trace: [ 4155.708606] [8168d303] ? dump_stack+0x40/0x50 [ 4155.708609] [8106d2d2] ? warn_slowpath_common+0x72/0xc0 [ 4155.708611] [8121b6f8] ? btrfs_destroy_inode+0x278/0x2a0 [ 4155.708614] [81129381] ? dispose_list+0x41/0x60 [ 4155.708615] [81129669] ? prune_icache_sb+0x49/0x60 [ 4155.708618] [8111205a] ? super_cache_scan+0x13a/0x1a0 [ 4155.708621] [810e0a1b] ? shrink_slab.part.52.constprop.62+0x19b/0x240 [ 4155.708623] [810e3049] ? shrink_zone+0x89/0xa0 [ 4155.708625] [810e3241] ? try_to_free_pages+0x1e1/0x320 [ 4155.708626] [810daa82] ? __alloc_pages_nodemask+0x382/0x680 [ 4155.708629] [810f597d] ? handle_mm_fault+0xbbd/0xe60 [ 4155.708631] [81092e15] ? put_prev_task_fair+0x75/0x320 [ 4155.708632] [810903b0] ? __dequeue_entity+0x30/0x40 [ 4155.708633] [81094975] ? pick_next_task_fair+0x415/0x480 [ 4155.708636] [81064144] ? __do_page_fault+0x104/0x3a0 [ 4155.708637] [8168fb77] ? __schedule+0x257/0x860 [ 4155.708639] [8169518f] ? page_fault+0x1f/0x30 [ 4155.708640] ---[ end trace 265993ee076d84aa ]--- [ 4155.708641] [ cut here ] [ 4155.708643] WARNING: CPU: 1 PID: 8850 at fs/btrfs/inode.c:8694 btrfs_destroy_inode+0x1f2/0x2a0() [ 4155.708644] CPU: 1 PID: 8850 Comm: lto1-wpa-stream Tainted: GW 3.19.0-08975-g3d883483dc0a-dirty #101 [ 4155.708645] Hardware name: System manufacturer System Product Name/M4A78T-E, BIOS 350304/13/2011 [ 4155.708645] 81999aad 8168d303 [ 4155.708647] 8106d2d2 8800dad9bb78 88018554ccc0 880215e2e000 [ 4155.708648] 880215f23000 8121b672 [ 4155.708649] Call Trace: [ 4155.708651] [8168d303] ? dump_stack+0x40/0x50 [ 4155.708652] [8106d2d2] ? warn_slowpath_common+0x72/0xc0 [ 4155.708654] [8121b672] ? btrfs_destroy_inode+0x1f2/0x2a0 [ 4155.708655] [81129381] ? dispose_list+0x41/0x60 [ 4155.708656] [81129669] ? prune_icache_sb+0x49/0x60 [ 4155.708658] [8111205a] ? super_cache_scan+0x13a/0x1a0 [ 4155.708659] [810e0a1b] ? shrink_slab.part.52.constprop.62+0x19b/0x240 [ 4155.708661] [810e3049] ? shrink_zone+0x89/0xa0 [ 4155.708662] [810e3241] ? try_to_free_pages+0x1e1/0x320 [ 4155.708664] [810daa82] ? __alloc_pages_nodemask+0x382/0x680 [ 4155.708665] [810f597d] ? handle_mm_fault+0xbbd/0xe60 [ 4155.708667] [81092e15] ? put_prev_task_fair+0x75/0x320 [ 4155.708668] [810903b0] ? __dequeue_entity+0x30/0x40 [ 4155.708669] [81094975] ? pick_next_task_fair+0x415/0x480 [ 4155.708670] [81064144] ? __do_page_fault+0x104/0x3a0 [ 4155.708672] [8168fb77] ? __schedule+0x257/0x860 [ 4155.708673] [8169518f] ? page_fault+0x1f/0x30 [ 4155.708674] ---[ end trace 265993ee076d84ab ]--- [ 4156.021127] [ cut here ] [ 4156.021136] WARNING: CPU: 3 PID: 35 at fs/btrfs/inode.c:8693 btrfs_destroy_inode+0x278/0x2a0() [ 4156.021139] CPU: 3 PID: 35 Comm: kswapd0 Tainted: GW 3.19.0-08975-g3d883483dc0a-dirty #101 [ 4156.021140] Hardware name: System manufacturer System Product Name/M4A78T-E, BIOS 350304/13/2011 [ 4156.021141] 81999aad 8168d303 [ 4156.021143] 8106d2d2 8802160dfcb8 88006b07a690 880215e2e000 [ 4156.021145] 880215f23000
Re: Documenting MS_LAZYTIME
On Feb 20, 2015, at 1:50 AM, Michael Kerrisk mtk.manpa...@gmail.com wrote: Hello Ted, Based on your commit message 0ae45f63d4e, I I wrote the documentation below for MS_LAZYTIME, to go into the mount(2) man page. Could you please check it over and let me know if it's accurate. In particular, I added pieces marked with * below that were not part of the commit message and I'd like confirmation that they're accurate. Thanks, Michael [[ MS_LAZYTIME (since Linux 3.20) Only update filetimes (atime, mtime, ctime) on the in- memory version of the file inode. The on-disk time‐ stamps are updated only when: (a) the inode needs to be updated for some change unre‐ lated to file timestamps; (b) the application employs fsync(2), syncfs(2), or sync(2); (c) an undeleted inode is evicted from memory; or * (d) more than 24 hours have passed since the i-node was * written to disk. This mount option significantly reduces writes to the inode table for workloads that perform frequent random writes to preallocated files. * As at Linux 3.20, this option is supported only on ext4. I _think_ that the lazytime mount option is generic for all filesystems. I believe ext4 has an extra optimization for it, but that's it. Cheers, Andreas -- 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: [PATCH] Btrfs: fix allocation size calculations in alloc_btrfs_bio
On Thu, Feb 19, 2015 at 08:59:30PM -0500, Chris Mason wrote: Since commit 8e5cfb55d3f (Btrfs: Make raid_map array be inlined in btrfs_bio structure), the raid map array is allocated along with the btrfs bio in alloc_btrfs_bio. The calculation used to decide how much we need to allocate was using the wrong parameter passed into the allocation function. The passed in real_stripes will be zero if a target replace operation is not currently running. We want to use total_stripes instead. Signed-off-by: Chris Mason c...@fb.com Reported-by: Dave Sterba dste...@suse.cz Tested-by: David Sterba dste...@suse.cz Current master + this patch with full slub_debug is now ok with btrfs/023. -- 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: [PATCH] Btrfs: fix allocation size calculations in alloc_btrfs_bio
On Fri, Feb 20, 2015 at 9:35 AM, David Sterba dste...@suse.cz wrote: On Thu, Feb 19, 2015 at 08:59:30PM -0500, Chris Mason wrote: Since commit 8e5cfb55d3f (Btrfs: Make raid_map array be inlined in btrfs_bio structure), the raid map array is allocated along with the btrfs bio in alloc_btrfs_bio. The calculation used to decide how much we need to allocate was using the wrong parameter passed into the allocation function. The passed in real_stripes will be zero if a target replace operation is not currently running. We want to use total_stripes instead. Signed-off-by: Chris Mason c...@fb.com Reported-by: Dave Sterba dste...@suse.cz Tested-by: David Sterba dste...@suse.cz Current master + this patch with full slub_debug is now ok with btrfs/023. Thanks Dave. It also survived all night with raid6 and stress.sh. I'm sending to Linus today. -chris -- 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: [PATCH 0/3] btrfs: ENOMEM bugfixes
On Tue, Feb 17, 2015 at 02:51:06AM -0800, Omar Sandoval wrote: Hi, As it turns out, running with low memory is a really easy way to shake out undesirable behavior in Btrfs. This can be especially bad when considering that a memory limit is really easy to hit in a container (e.g., by using cgroup memory.limit_in_bytes). Here's a simple script that can hit several problems: #!/bin/sh cgcreate -g memory:enomem MEM=$((64 * 1024 * 1024)) echo $MEM /sys/fs/cgroup/memory/enomem/memory.limit_in_bytes cgexec -g memory:enomem ~/xfstests/ltp/fsstress -p128 -n9 -d /mnt/test trap killall fsstress; exit 0 SIGINT SIGTERM while true; do cgexec -g memory:enomem python -c ' l = [] while True: l.append(0)' done Ignoring for now the cases that drop the filesystem into read-only mode with relatively little fuss, here are a few patches that fix some of the low-hanging fruit. They apply to Linus' tree as of today. So I didn't realize this until I saw Tetsuo Handa's email to the ext4 list (http://thread.gmane.org/gmane.comp.file-systems.ext4/47855), but it looks like this behavior was exposed by a change to the kernel memory allocator related to the too-small-to-fail allocation fiasco. To summarize, Commit 9879de7373fc (mm: page_alloc: embed OOM killing naturally into allocation slowpath), merged for v3.19-rc7, changed the behavior of GFP_NOFS allocations which makes it much easier to trigger allocation failures in filesystems. This means that Btrfs falls over under memory pressure pretty easily now, so it might be a good idea to follow the conversation over at linux-mm (http://thread.gmane.org/gmane.linux.kernel.mm/126398). These are bugs regardless of the outcome there, however, so I'd like to see this patch series merged. Thanks again! Thanks! Omar Sandoval (3): btrfs: handle ENOMEM in btrfs_alloc_tree_block btrfs: handle race on ENOMEM in alloc_extent_buffer btrfs: check io_ctl_prepare_pages return in __btrfs_write_out_cache fs/btrfs/extent-tree.c | 41 - fs/btrfs/extent_io.c| 20 fs/btrfs/free-space-cache.c | 10 ++ 3 files changed, 50 insertions(+), 21 deletions(-) -- 2.3.0 -- Omar -- 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: [PATCH 0/3] btrfs: ENOMEM bugfixes
On 02/20/2015 04:20 PM, Omar Sandoval wrote: On Tue, Feb 17, 2015 at 02:51:06AM -0800, Omar Sandoval wrote: Hi, As it turns out, running with low memory is a really easy way to shake out undesirable behavior in Btrfs. This can be especially bad when considering that a memory limit is really easy to hit in a container (e.g., by using cgroup memory.limit_in_bytes). Here's a simple script that can hit several problems: #!/bin/sh cgcreate -g memory:enomem MEM=$((64 * 1024 * 1024)) echo $MEM /sys/fs/cgroup/memory/enomem/memory.limit_in_bytes cgexec -g memory:enomem ~/xfstests/ltp/fsstress -p128 -n9 -d /mnt/test trap killall fsstress; exit 0 SIGINT SIGTERM while true; do cgexec -g memory:enomem python -c ' l = [] while True: l.append(0)' done Ignoring for now the cases that drop the filesystem into read-only mode with relatively little fuss, here are a few patches that fix some of the low-hanging fruit. They apply to Linus' tree as of today. So I didn't realize this until I saw Tetsuo Handa's email to the ext4 list (https://urldefense.proofpoint.com/v1/url?u=http://thread.gmane.org/gmane.comp.file-systems.ext4/47855k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=cKCbChRKsMpTX8ybrSkonQ%3D%3D%0Am=nzG8bjaiVMyWylHxOvTeXimzfSNyukj4%2BAxs0AZ%2FxOI%3D%0As=cbd7d48f1866e79f75b88b7f94a394c53d34adfcc1a30a842382f653c978e180), but it looks like this behavior was exposed by a change to the kernel memory allocator related to the too-small-to-fail allocation fiasco. To summarize, Commit 9879de7373fc (mm: page_alloc: embed OOM killing naturally into allocation slowpath), merged for v3.19-rc7, changed the behavior of GFP_NOFS allocations which makes it much easier to trigger allocation failures in filesystems. This means that Btrfs falls over under memory pressure pretty easily now, so it might be a good idea to follow the conversation over at linux-mm (https://urldefense.proofpoint.com/v1/url?u=http://thread.gmane.org/gmane.linux.kernel.mm/126398k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=cKCbChRKsMpTX8ybrSkonQ%3D%3D%0Am=nzG8bjaiVMyWylHxOvTeXimzfSNyukj4%2BAxs0AZ%2FxOI%3D%0As=5177c5ceb03f82d8abb0beeeb4dc5e0c45cc77e9687881590e3ef1701f069a85). These are bugs regardless of the outcome there, however, so I'd like to see this patch series merged. Yeah I'm fine with this, your stuff fixes actual problems and they look sane so I'm cool with taking them. Regardless of what the mm guys do we shouldn't fall over horribly when allocations fail. Thanks, Josef -- 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: scrub problem
On Fri, 2015-02-20 at 20:59 +0100, Johan Kröckel wrote: The scrub is neither cancelable not stoppable. What is the problem? [ root@host]# btrfs scrub status ./ scrub status for XX----XX scrub started at Thu Feb 19 12:41:22 2015, running for 16964 seconds total bytes scrubbed: 1.56TiB with 0 errors [ root@host]# btrfs scrub cancel ./ ERROR: scrub cancel failed on ./: not running [ root@host]# btrfs scrub start ./ ERROR: scrub is already running. To cancel use 'btrfs scrub cancel ./'. To see the status use 'btrfs scrub status [-d] ./'. You don't say here which version of btrfs-progs you are using... As Bob said, this issue is caused by a desynchronization between the state file on the drive and the kernel state. However, code was added to btrfs-progs 3.17 to detect and correct this condition. I'd suggest updating your btrfs-progs. -- Calvin Walton calvin.wal...@kepstin.ca -- 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: Documenting MS_LAZYTIME
On 2/20/15 2:50 AM, Michael Kerrisk wrote: Hello Ted, Based on your commit message 0ae45f63d4e, I I wrote the documentation below for MS_LAZYTIME, to go into the mount(2) man page. Could you please check it over and let me know if it's accurate. In particular, I added pieces marked with * below that were not part of the commit message and I'd like confirmation that they're accurate. Thanks, Michael [[ MS_LAZYTIME (since Linux 3.20) Only update filetimes (atime, mtime, ctime) on the in- memory version of the file inode. The on-disk time‐ stamps are updated only when: filetimes and file inode seems a bit awkward. How about: MS_LAZYTIME (since Linux 3.20) Reduce on-disk updates of inode timestamps (atime, mtime, ctime) by maintaining these changes only in memory, unless: (maybe I'm bike-shedding too much, if so, sorry). (a) the inode needs to be updated for some change unre‐ lated to file timestamps; (b) the application employs fsync(2), syncfs(2), or sync(2); (c) an undeleted inode is evicted from memory; or * (d) more than 24 hours have passed since the i-node was * written to disk. Please don't use i-node - simply inode is much more common in the manpages AFAICT. This mount option significantly reduces writes to the inode table for workloads that perform frequent random writes to preallocated files. This seems like an overly specific description of a single workload out of many which may benefit, but what do others think? inode table is also fairly extN-specific. -Eric * As at Linux 3.20, this option is supported only on ext4. ]] -- 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: Documenting MS_LAZYTIME
On Fri, Feb 20, 2015 at 09:49:34AM -0600, Eric Sandeen wrote: This mount option significantly reduces writes to the inode table for workloads that perform frequent random writes to preallocated files. This seems like an overly specific description of a single workload out of many which may benefit, but what do others think? inode table is also fairly extN-specific. How about somethign like This mount significantly reduces writes needed to update the inode's timestamps, especially mtime and actime. Examples of workloads where this could be a large win include frequent random writes to preallocated files, as well as cases where the MS_STRICTATIME mount option is enabled.? (The advantage of MS_STRICTATIME | MS_LAZYTIME is that stat system calls will return the correctly updated atime, but those atime updates won't get flushed to disk unless the inode needs to be updated for file system / data consistency reasons, or when the inode is pushed out of memory, or when the file system is unmounted.) - Ted -- 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: Documenting MS_LAZYTIME
On 02/20/2015 04:49 PM, Eric Sandeen wrote: On 2/20/15 2:50 AM, Michael Kerrisk wrote: Hello Ted, Based on your commit message 0ae45f63d4e, I I wrote the documentation below for MS_LAZYTIME, to go into the mount(2) man page. Could you please check it over and let me know if it's accurate. In particular, I added pieces marked with * below that were not part of the commit message and I'd like confirmation that they're accurate. Thanks, Michael [[ MS_LAZYTIME (since Linux 3.20) Only update filetimes (atime, mtime, ctime) on the in- memory version of the file inode. The on-disk time‐ stamps are updated only when: filetimes and file inode seems a bit awkward. How about: MS_LAZYTIME (since Linux 3.20) Reduce on-disk updates of inode timestamps (atime, mtime, ctime) by maintaining these changes only in memory, unless: (maybe I'm bike-shedding too much, if so, sorry). Nah it''s the good sort of bikeshedding ;-). filetimes was a wordo--I meant timestamps. I've taken your wording mostly. (a) the inode needs to be updated for some change unre‐ lated to file timestamps; (b) the application employs fsync(2), syncfs(2), or sync(2); (c) an undeleted inode is evicted from memory; or * (d) more than 24 hours have passed since the i-node was * written to disk. Please don't use i-node - simply inode is much more common in the manpages AFAICT. Yup, that was a typo. Fixed. This mount option significantly reduces writes to the inode table for workloads that perform frequent random writes to preallocated files. This seems like an overly specific description of a single workload out of many which may benefit, but what do others think? Fair enough. I reworded that to note it as an example. inode table is also fairly extN-specific. I'll await further input on that point. Now we have: MS_LAZYTIME (since Linux 3.20) Reduce on-disk updates of inode timestamps (atime, mtime, ctime) by maintaining these changes only in mem‐ ory. The on-disk timestamps are updated only when: (a) the inode needs to be updated for some change unre‐ lated to file timestamps; (b) the application employs fsync(2), syncfs(2), or sync(2); (c) an undeleted inode is evicted from memory; or (d) more than 24 hours have passed since the inode was written to disk. This mount option significantly reduces writes to the inode table for some workloads (e.g., when performing frequent random writes to preallocated files). Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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: scrub problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/02/15 19:59, Johan Kröckel wrote: The scrub is neither cancelable not stoppable. What is the problem? [root@host ]# btrfs scrub status ./ scrub status for XX----XX scrub started at Thu Feb 19 12:41:22 2015, running for 16964 seconds total bytes scrubbed: 1.56TiB with 0 errors [root@host ]# btrfs scrub cancel ./ ERROR: scrub cancel failed on ./: not running [root@host ]# btrfs scrub start ./ ERROR: scrub is already running. To cancel use 'btrfs scrub cancel ./'. To see the status use 'btrfs scrub status [-d] ./'. -- If the local state file used to track scrub history has become desynchronized, fix it by editing the file /var/lib/btrfs/scrub.status.0b07b829-9a0e-44ab-89ee-14b36a45199e (the last bit of the filename is the filesystem uuid) Look for a line that ends with finished:0 and change it to say finished:1 Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlTnoSUACgkQ0Sr7eZJrmU75sQCcDTJvEufEFVaO8hgHp5SC81Lr DUwAn2rKiCiyu7k0/6svdfhmlbFpn12B =/2xH -END PGP SIGNATURE- -- 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
scrub problem
The scrub is neither cancelable not stoppable. What is the problem? [root@host ]# btrfs scrub status ./ scrub status for XX----XX scrub started at Thu Feb 19 12:41:22 2015, running for 16964 seconds total bytes scrubbed: 1.56TiB with 0 errors [root@host ]# btrfs scrub cancel ./ ERROR: scrub cancel failed on ./: not running [root@host ]# btrfs scrub start ./ ERROR: scrub is already running. To cancel use 'btrfs scrub cancel ./'. To see the status use 'btrfs scrub status [-d] ./'. -- 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
