Btrfs progs pre-release 4.8-rc1
Hi, btrfs-progs 4.8-rc1 have been tagged. There are almost no user-visible changes besides the docs updates. Added lots of improved error handling, new fuzzed images and related fixes and some minor cleanups. There are some fuzz tests failing, I'll fix them before release but patches are welcome. The 4.8 ETA is this Wednesday (2016-10-05). Tarballs: https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/ Git: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git Shortlog: Adam Borowski (1): btrfs-progs: docs: document exit codes from scrub David Sterba (64): btrfs-progs: scrub: improved error handling in scrub_read_file btrfs-progs: fi usage: improved error handling in load_device_info btrfs-progs: dump-tree: improved error handling in print_extents btrfs-progs: dump-tree: improved error handling in cmd_inspect_dump_tree btrfs-progs: switch BUG_ON to ASSERT in reserve_free_space btrfs-progs: more verbose error handling in creation helpers btrfs-progs: mkfs: check for sane sectorsize earlier btrfs-progs: handle errors from btrfs_alloc_path btrfs-progs: receive: improved error handling in process_snapshot btrfs-progs: check: improved error handling in calc_extent_flag btrfs-progs: switch column values to asserts btrfs-progs: chunk-recover: improve error handling in insert_stripe btrfs-progs: mkfs: handle block ordering errors in make_btrfs btrfs-progs: convert: improve error handling in create_image_file_range btrfs-progs: catch invalid flags in open_ctree_fd btrfs-progs: remove trivial helpers for filtering functions btrfs-progs: qgroup: switch to common message helpers btrfs-progs: improved error handling in btrfs_print_tree btrfs-progs: inspect: improved error handling btrfs-progs: fi du: catch bogus extent lengths btrfs-progs: fi du: improved error handling in mark_inode_seen btrfs-progs: tree-stats: switch to common message helpers btrfs-progs: prop: simplify help printing code btrfs-progs: remove redundant check in btrfs_add_to_fsid btrfs-progs: improve error handling in btrfs_alloc_data_chunk btrfs-progs: dump-super: switch to common message helpers btrfs-progs: corrupt-block: improved error handling in corrupt_item_nocow btrfs-progs: improve error handling in btrfs_add_to_fsid btrfs-progs: use standard allocation functions in non-kenrel code btrfs-progs: check: handle errors returned by add_extent_rec_nolookup btrfs-progs: check: improve error handling in add_extent_rec_nolookup btrfs-progs: convert: improve error handling in do_rollback btrfs-progs: image: switch to common message helpers btrfs-progs: check: switch some messages to common helpers btrfs-progs: corrupt-block: fix assertion condition btrfs-progs: improve error handling in clone_inode_rec btrfs-progs: cleanup, kill trivial btrfs_set_key_type helper btrfs-progs: cleanup, kill trivial btrfs_key_type helper btrfs-progs: remove unused variable in add_inode_items btrfs-progs: use PATH_MAX in cmd_inspect_logical_resolve btrfs-progs: mkfs: remove useless helper btrfs-progs: tests: iterate over fuzzed images and test various tools btrfs-progs: tests: add script to scan results for some known runtime errors btrfs-progs: build: add basic support for subdirectory build btrfs-progs: move 3rd party kernel library modules to own directory btrfs-progs: restore: update help text btrfs-progs: remove stray function declaration btrfs-progs: don't write to optarg in btrfs_qgroup_parse_sort_string btrfs-progs: constify string arguments where appropriate btrfs-progs: image: use common message helpers btrfs-progs: btrfstune: use common message helpers btrfs-progs: more sanity checks in read_tree_block_fs_info btrfs-progs: tests: add fuzzed images with bad blocksize/lengh of eb btrfs-progs: check: better error handling in find_parent_roots btrfs-progs: tests: add fuzzed image with bad parent refs, qgroup-verify btrfs-progs: image: catch zero length extents, avoid endless loop btrfs-progs: image: return negativer error from all paths in mdrestore_init btrfs-progs: image: drop useless bug_on btrfs-progs: print value when assertion fails btrfs-progs: chunk-recover: handle duplicate cache entries btrfs-progs: don't access freed memory in btrfs_close_devices btrfs-progs: tests: split test 004 to separate tests btrfs-progs: tests: don't treat segfault as ignorable error Btrfs progs v4.8-rc1 Domagoj Tršan (1): btrfs-progs: change btrfs_csum_final result param type to u8 Lakshmipathi.G (1): btrfs-progs: convert: check source file system state Nicholas D Steeves (1): btrfs-progs: fix user-facing typos in docs and help strings Qu Wenr
Re: [PATCH v3] btrfs: fix a possible umount deadlock
On Thu, Sep 22, 2016 at 12:24:07PM -0400, Jeff Mahoney wrote: > This isn't necessarily a comment on this code in particular, but what's > the reason for using call_rcu to defer the freeing instead of > synchronize_rcu and freeing the device directly via __free_device (if it > accepted a btrfs_device)? It's a pattern that's used throughout > volumes.c and it's old[1]. I'm not sure if it was intentional to defer > freeing since that was actually a functional change from the code it > replaced. It could be unintentional, the patch was supposed to relax the read-only side, ie. use RCU instead of mutex. Deferred freeing does not seem to be necessary. The device locking code needs cleanup/refactoring. -- 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: Commit 'synchronize incompat feature bits with sysfs files' still missing in for-next?
On Tue, Sep 13, 2016 at 01:34:26PM +0200, Holger Hoffstätte wrote: > > I've noticed that the 4.5-rc commit 14e46e04: > 'btrfs: synchronize incompat feature bits with sysfs files' [1] > was reverted later in [2], but despite fixes to protect sysfs > with locks & exorcise GFP_NOFS in favor of GFP_KERNEL it was > never reinstated - neither for 4.5-final, nor later..and it's > been quite a while since then. Is this still valid? > > I ask because I've just noticed I've had this in my tree since > forever, but have never encountered a problem during balance - > probably because of all the other fixes. I spent sime time trying to fix it but got lost in sysfs. Supposedly, the attribute group functions should provide all what's needed, ie. define a set of attributes, visibility callback. Calling an update will, in theory and my expectations, refresh the values and files. It does not. IIRC it was never meant to work like that, so it would have to be worked around or new sysfs helpers adde or I don't know what else. Working with sysfs code is sometimes painful, but I'm about to return to adding the free-space-tree bits someday. -- 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: [RFC][PATCH] btrfs-progs: move sources shared with kernel to own directory
On Fri, Sep 30, 2016 at 09:11:30AM +0800, Qu Wenruo wrote: > > - cmds/ - (planned) cmds-*.[ch] > > Sounds good, so we can skip the "cmds-" prefix then. Yes. We have to start somewhere, file renaming is left for later. > > > - convert/- move as-is, split later, eg. per filsystem > > - image/ - move as-is, split if needed > > - check/ - split from cmds-check > > Pretty cool. > I'm also moving some code into its own dir doing the user-space scrub work. > (While I'm creating a new dir called fsck/ and put my scrub code into > it, rename it to check/ won't be a problem though) > > While I'm not sure what is going to be in kernel-shared/ dir. > > Uapi headers? or things like disk-io.c volumes.c? Headers and the files you mentioned. See the branch for complete list. The headers could be further separated, public and private. > For uapi headers, then kernel-shared/ may contain few files. > For disk-io.c/volumes.c, they are not shared with kernel anymore. Partial sharing should be enough. See changelong: > > All files that share content and purpose with the corresponding file in > > the kernel are moved to a separate directory. There's only some overlap, > > can't be 100% match but many functions are shared. A diff between the > > files can reveal changes that should be applied to the other codebase. . -- 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
[PULl] Btrfs, free-space-tree fixes for 4.9
Hi, this pull contains the important fixes to the bitmap handling when the free-space-tree feature is enabled on bigendian machines. Patches were tested on various arches, we still might need more testing on sparc64 as there were some problems unrelated to this patchset. Please pull, thanks. The following changes since commit 08895a8b6b06ed2323cd97a36ee40a116b3db8ed: Linux 4.8-rc8 (2016-09-25 18:47:13 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git fst-fixes for you to fetch changes up to 0e6757859efea6ed919fc37e4ee468634220b2d2: btrfs: tests: uninline member definitions in free_space_extent (2016-10-03 18:52:15 +0200) David Sterba (2): btrfs: tests: constify free space extent specs btrfs: tests: uninline member definitions in free_space_extent Omar Sandoval (5): Btrfs: fix free space tree bitmaps on big-endian systems Btrfs: fix mount -o clear_cache,space_cache=v2 Btrfs: catch invalid free space trees Btrfs: fix extent buffer bitmap tests on big-endian systems Btrfs: expand free space tree sanity tests to catch endianness bug fs/btrfs/ctree.h | 3 +- fs/btrfs/disk-io.c | 33 +++--- fs/btrfs/extent_io.c | 64 +++ fs/btrfs/extent_io.h | 22 fs/btrfs/free-space-tree.c | 19 ++-- fs/btrfs/tests/extent-io-tests.c | 87 --- fs/btrfs/tests/free-space-tree-tests.c | 189 +++-- include/uapi/linux/btrfs.h | 12 ++- 8 files changed, 272 insertions(+), 157 deletions(-) -- 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: 4.8rc8 & OOM panic
On 09/28/16 21:45, Holger Hoffstätte wrote: > On 09/28/16 20:46, E V wrote: >> I just booted my backup box with 4.8rc8 and started an rsync onto >> btrfs and it panic'd with OOM a couple hours later. I thought the OOM >> problems from 4.7 we're supposed to be fixed in 4.8, or did I get that >> wrong? No users or anything else on the system. > > Keep in mind that those problems are generic, other filesystems also > suffer: http://www.spinics.net/lists/linux-mm/msg114123.html > > I don't see any recent compaction-related patches in Linus' tree at > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/mm/ Sorry, that was not quite correct. -stable 4.7.x and 4.8 contain a workaround (http://goo.gl/DiwfPH) that is supposed to help. That went into 4.8rc8 already, so not sure what happened in your case. > So unless they get merged in the last minute it looks like 4.8 will > be DOA. Running 4.8 final now, let's see what happens.. -h -- 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: Problem with btrfs fs in 4.1.25 (also 4.8.0) - getting EBUSY on file create - kernel.org bug 173001
Dave Olson wrote: > The full details are in > https://bugzilla.kernel.org/show_bug.cgi?id=173001 > > Basicly, logrotate has rotated a file to a new name, tries to open a new > file with the original name, and gets EBUSY. The file is not created. > > Later on the file can be created with no problems. > > I've turned on most of the BTRFS config options, and there are no BTRFS > messages related to the failure. > > The file is on the root filesystem. This problem is also reproducible on a 4.8 kernel.org kernel with no modifications, built today from the 4.8 tag. It happened on the 77th powercycle, after about 3 hours. Dave Olson ol...@cumulusnetworks.com -- 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
