Re: [PATCH 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand.
Original Message Subject: Re: [PATCH 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand. From: Hugo Mills h...@carfax.org.uk To: dste...@suse.cz, Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org, c...@fb.com Date: 2014年05月18日 01:43 On Wed, Apr 16, 2014 at 07:12:19PM +0200, David Sterba wrote: On Wed, Apr 02, 2014 at 04:29:11PM +0800, Qu Wenruo wrote: Convert the old btrfs man pages to new asciidoc and split the huge btrfs man page into subcommand man page. I'm merging this patchset into the base series of integration because several patches need to update the docs and it's no longer feasible to keep it in a separate branch from the patches. I've just been poking around in the docs for a completely different reason, and I think there's a fairly serious problem (well, as serious as problems get with documentation). Take, for example, the format for btrfs fi resize: 'resize' [devid:][+/-]size[gkm]|[devid:]max path:: Now, this has just thrown away all of the useful markup which indicates the semantics of the command. The asciidoc renders all of that text literally and unformatted, making alphasymbolic(*) soup of the docs. Compare this to the old roff man page: \fBbtrfs\fP \fBfilesystem resize\fP [\fIdevid\fP:][+/\-]\fIsize\fP[gkm]|[\fIdevid\fP:]\fImax path\fP Yes, When I convert man pages to asciidoc docs, I have already realized the problem. As mentioned in first patch, most things including the Makefile is 'stolen' from git, which means I also apply the git way to deal with the all 'useful' markups, *just throw them away* . This isn't perfect -- we're missing a \fB around the max -- but it has text in bold(⁑) and italics(⁂) and neither(☃). I've just looked at some of the other pages, and they've also got similar typographical problems. This is a lot of fiddly tedious work to get it right, and if it doesn't get done now in the initial commit, then we're going to end up with poor examples copied for every new feature or docs update, making the problem worse before anyone does the work to make it better. As I mentions above, it's meant to be like this, without extra markup just like git. I choose asciidoc and the git documentation style for the following purpose: 1) Split up the huge 'btrfs' man page. (Main purpose of the patchset) The 'btrfs' man page is so huge that the synopsis is serveral pages long, force developers to edit man page twice(one for synopsis and one for command). This makes editing frustrating and easy to make things inconsistent. (serveral synopsis and command description are already inconsistent) 2) Make the documenation more general purpose. (Why choose asciidoc) Not only generating man pages, but also html/pdf, much like git. 3) Make the original txt more human readable (Why choose git style) I can use the old markup method but after doing that I realize if you read a document full of markups, the markups have alread lost their meaning. If using too many markup, there will be other problems: 3.1) making the synopsis in original txt too long This will make both developer and reviewer harder to edit/review. I choose asciidoc to reduce the hard-to-understand groff grammar, if these \fX are just converted to ' or `, IMO the cost is still not cut. 3.2) the markup is not so highlighted if every thing is highlighted So I choose only to highlight really important things, since with all the bold and itatlic things full of the page, there is no difference between all normal formatted text. Due to the above 3 reasons, I think throwing all markup in synopsis is a better choice. Thanks, Qu Hugo. (*) Or possibly alphashambolic. :) (⁑) For literal text (⁂) For variables that require substitution by the user (☃) For structural syntax indicators such as [] for optional parts, | for alternation and ... to indicate optional continuation of a list -- 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 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand.
Original Message Subject: Re: [PATCH 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand. From: Hugo Mills h...@carfax.org.uk To: dste...@suse.cz, Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org, c...@fb.com Date: 2014年05月18日 02:22 On Sat, May 17, 2014 at 06:43:15PM +0100, Hugo Mills wrote: On Wed, Apr 16, 2014 at 07:12:19PM +0200, David Sterba wrote: On Wed, Apr 02, 2014 at 04:29:11PM +0800, Qu Wenruo wrote: Convert the old btrfs man pages to new asciidoc and split the huge btrfs man page into subcommand man page. I'm merging this patchset into the base series of integration because several patches need to update the docs and it's no longer feasible to keep it in a separate branch from the patches. I've just been poking around in the docs for a completely different reason, and I think there's a fairly serious problem (well, as serious as problems get with documentation). Take, for example, the format for btrfs fi resize: 'resize' [devid:][+/-]size[gkm]|[devid:]max path:: Now, this has just thrown away all of the useful markup which indicates the semantics of the command. The asciidoc renders all of that text literally and unformatted, making alphasymbolic(*) soup of the docs. Compare this to the old roff man page: \fBbtrfs\fP \fBfilesystem resize\fP [\fIdevid\fP:][+/\-]\fIsize\fP[gkm]|[\fIdevid\fP:]\fImax path\fP This isn't perfect -- we're missing a \fB around the max -- but it has text in bold(⁑) and italics(⁂) and neither(☃). I've just looked at some of the other pages, and they've also got similar typographical problems. This is a lot of fiddly tedious work to get it right, and if it doesn't get done now in the initial commit, then we're going to end up with poor examples copied for every new feature or docs update, making the problem worse before anyone does the work to make it better. Oh, and asciidoc appears to be the most horrible capricious inconsistent parser in existence. I've just spent 5 minutes getting this one line of text to do what I want it to: = __N__**c**[\[_Mmin_**-**]__Mmax__**s**[_P_**p**]] = I had to run through the list of block quote operators one at a time in order to find the one I needed for this (the =); it's still not indenting it correctly on the resulting man page. Note also the fun things like the fact that [[]] is special, so you have to quote the opening part of it -- but if you try quoting the first [ with a \ you get a literal \[ in the output. You get the right output from quoting the *second* [ only. I have already encountered problems like that, especially when convert 'btrfs-resize' related things. But wait for a minute, do we really need the *fascinating* highlight things in a user documentation? The most important thing is the content not the format. I choose asciidoc to make developers take less effort on the format things, not the opposite. In this point of view, I think asciidoc does things considerately well. Although the problem you mentioned is true, but it only affects a small part of the documentation, compared to the overall benefits, I still consider converting to asciidoc is worthy. The Nc can only be italicised and emboldened properly with __ and ** because _ and * require whitespace around them in order to work (seriously, WTF?). However, we can't be consistent with that in the _Mmin_**-** because the quoted \[ appears to count as whitespace, so using __Mmin__ gives us a leading literal _. The closing __ appears to close the single opening _ correctly in that case, though. Seriously, this is meant to be _easy_ to use? I think I'd rather type docbook by hand that have to struggle with this. Even the troff macros for man pages are simpler to get right. From the purpose of documentation and the above explaination, I think the answer is *Yes*. If you really think there is a better choice, I will be very happy to listen, but please consider what I mentioned above and the privious mail first. Thanks, Qu. Hugo. Hugo. (*) Or possibly alphashambolic. :) (⁑) For literal text (⁂) For variables that require substitution by the user (☃) For structural syntax indicators such as [] for optional parts, | for alternation and ... to indicate optional continuation of a list -- 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 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand.
On Sun, May 18, 2014 at 02:51:39PM +0800, Qu Wenruo wrote: Original Message Subject: Re: [PATCH 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand. From: Hugo Mills h...@carfax.org.uk To: dste...@suse.cz, Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org, c...@fb.com Date: 2014年05月18日 01:43 On Wed, Apr 16, 2014 at 07:12:19PM +0200, David Sterba wrote: On Wed, Apr 02, 2014 at 04:29:11PM +0800, Qu Wenruo wrote: Convert the old btrfs man pages to new asciidoc and split the huge btrfs man page into subcommand man page. I'm merging this patchset into the base series of integration because several patches need to update the docs and it's no longer feasible to keep it in a separate branch from the patches. I've just been poking around in the docs for a completely different reason, and I think there's a fairly serious problem (well, as serious as problems get with documentation). Take, for example, the format for btrfs fi resize: 'resize' [devid:][+/-]size[gkm]|[devid:]max path:: Now, this has just thrown away all of the useful markup which indicates the semantics of the command. The asciidoc renders all of that text literally and unformatted, making alphasymbolic(*) soup of the docs. Compare this to the old roff man page: \fBbtrfs\fP \fBfilesystem resize\fP [\fIdevid\fP:][+/\-]\fIsize\fP[gkm]|[\fIdevid\fP:]\fImax path\fP Yes, When I convert man pages to asciidoc docs, I have already realized the problem. As mentioned in first patch, most things including the Makefile is 'stolen' from git, which means I also apply the git way to deal with the all 'useful' markups, *just throw them away* . This isn't perfect -- we're missing a \fB around the max -- but it has text in bold(⁑) and italics(⁂) and neither(☃). I've just looked at some of the other pages, and they've also got similar typographical problems. This is a lot of fiddly tedious work to get it right, and if it doesn't get done now in the initial commit, then we're going to end up with poor examples copied for every new feature or docs update, making the problem worse before anyone does the work to make it better. As I mentions above, it's meant to be like this, without extra markup just like git. I choose asciidoc and the git documentation style for the following purpose: 1) Split up the huge 'btrfs' man page. (Main purpose of the patchset) The 'btrfs' man page is so huge that the synopsis is serveral pages long, force developers to edit man page twice(one for synopsis and one for command). This makes editing frustrating and easy to make things inconsistent. (serveral synopsis and command description are already inconsistent) I don't have a problem with that, but it's irrelevant to my point. 2) Make the documenation more general purpose. (Why choose asciidoc) Not only generating man pages, but also html/pdf, much like git. I have no objections at all to that either. It's a great idea. But again, it's orthogonal to my main point here, which is that we've lost useful semantics, because the markup _is_ part of the meaning of the document. 3) Make the original txt more human readable (Why choose git style) I can use the old markup method but after doing that I realize if you read a document full of markups, the markups have alread lost their meaning. If using too many markup, there will be other problems: 3.1) making the synopsis in original txt too long This will make both developer and reviewer harder to edit/review. I choose asciidoc to reduce the hard-to-understand groff grammar, if these \fX are just converted to ' or `, IMO the cost is still not cut. I don't think we should be throwing away meaning just because it makes things shorter in the source. 3.2) the markup is not so highlighted if every thing is highlighted So I choose only to highlight really important things, since with all the bold and itatlic things full of the page, there is no difference between all normal formatted text. I'm only talking about two things: the syntactic summaries, where we need to distinguish between literals, placeholders and descriptive elements like []; and command text where we distinguish between the descriptive English text and the stuff you type. This second point is particularly important for us because so many of our commands consist of recognisable English words strung together, and having the literal commands shown in a distinctive style (typically a monospace font) helps enormously with parsing the text when reading at speed. Due to the above 3 reasons, I think throwing all markup in synopsis is a better choice. I disagree strongly. Hugo. Thanks, Qu Hugo. (*) Or possibly alphashambolic. :) (⁑) For literal text (⁂) For variables that require substitution by the user (☃) For
Re: [PATCH 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand.
On Sun, May 18, 2014 at 03:04:33PM +0800, Qu Wenruo wrote: Original Message Subject: Re: [PATCH 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand. From: Hugo Mills h...@carfax.org.uk To: dste...@suse.cz, Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org, c...@fb.com Date: 2014年05月18日 02:22 On Sat, May 17, 2014 at 06:43:15PM +0100, Hugo Mills wrote: On Wed, Apr 16, 2014 at 07:12:19PM +0200, David Sterba wrote: On Wed, Apr 02, 2014 at 04:29:11PM +0800, Qu Wenruo wrote: Convert the old btrfs man pages to new asciidoc and split the huge btrfs man page into subcommand man page. I'm merging this patchset into the base series of integration because several patches need to update the docs and it's no longer feasible to keep it in a separate branch from the patches. I've just been poking around in the docs for a completely different reason, and I think there's a fairly serious problem (well, as serious as problems get with documentation). Take, for example, the format for btrfs fi resize: 'resize' [devid:][+/-]size[gkm]|[devid:]max path:: Now, this has just thrown away all of the useful markup which indicates the semantics of the command. The asciidoc renders all of that text literally and unformatted, making alphasymbolic(*) soup of the docs. Compare this to the old roff man page: \fBbtrfs\fP \fBfilesystem resize\fP [\fIdevid\fP:][+/\-]\fIsize\fP[gkm]|[\fIdevid\fP:]\fImax path\fP This isn't perfect -- we're missing a \fB around the max -- but it has text in bold(⁑) and italics(⁂) and neither(☃). I've just looked at some of the other pages, and they've also got similar typographical problems. This is a lot of fiddly tedious work to get it right, and if it doesn't get done now in the initial commit, then we're going to end up with poor examples copied for every new feature or docs update, making the problem worse before anyone does the work to make it better. Oh, and asciidoc appears to be the most horrible capricious inconsistent parser in existence. I've just spent 5 minutes getting this one line of text to do what I want it to: = __N__**c**[\[_Mmin_**-**]__Mmax__**s**[_P_**p**]] = I had to run through the list of block quote operators one at a time in order to find the one I needed for this (the =); it's still not indenting it correctly on the resulting man page. Note also the fun things like the fact that [[]] is special, so you have to quote the opening part of it -- but if you try quoting the first [ with a \ you get a literal \[ in the output. You get the right output from quoting the *second* [ only. I have already encountered problems like that, especially when convert 'btrfs-resize' related things. But wait for a minute, do we really need the *fascinating* highlight things in a user documentation? Yes, absolutely. The formatting is a part of the _meaning_ of the documentation. Otherwise you're left guessing as to which pieces of the string of characters are meant to be there literally, and which pieces have to be replaced by suitable text, and which pieces are optional. The most important thing is the content not the format. My point is that in this case the formatting _is_ a part of the content. I choose asciidoc to make developers take less effort on the format things, not the opposite. In this point of view, I think asciidoc does things considerately well. Although the problem you mentioned is true, but it only affects a small part of the documentation, compared to the overall benefits, I still consider converting to asciidoc is worthy. I'm finding it almost impossible to make it do what I want. I think in some cases it actually _is_ impossible. This is a truly frustrating tool that is really not making things simpler, and I can see is going to lead to even more badly marked up documentation -- simply because it's too difficult and frustrating to get it right. The Nc can only be italicised and emboldened properly with __ and ** because _ and * require whitespace around them in order to work (seriously, WTF?). However, we can't be consistent with that in the _Mmin_**-** because the quoted \[ appears to count as whitespace, so using __Mmin__ gives us a leading literal _. The closing __ appears to close the single opening _ correctly in that case, though. Seriously, this is meant to be _easy_ to use? I think I'd rather type docbook by hand that have to struggle with this. Even the troff macros for man pages are simpler to get right. From the purpose of documentation and the above explaination, I think the answer is *Yes*. Only if you don't care about the typography of the resulting document. If you really think there is a better choice, I will be very happy to listen, but please consider what I mentioned above and the privious mail first. I don't have any real suggestions
Re: [PATCH 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand.
On 2014/05/18 02:05 PM, Hugo Mills wrote: On Sun, May 18, 2014 at 03:04:33PM +0800, Qu Wenruo wrote: I don't have any real suggestions for alternatives coming from my experience, other than not this. I've used docbook for man pages briefly, many years ago. Looking around on the web, reStructuredText might be a good option. Personally, I'd like to write docs in LaTeX, but I'm not sure how easy it is to convert that to man pages. Hugo. What I have read so far indicates that LaTeX is the simplest most beautiful way to create portable documentation - and that exporting to a man page is simple. I can't vouch for it except to say that it is worth investigating. -- __ Brendan Hide http://swiftspirit.co.za/ http://www.webafrica.co.za/?AFF1E97 -- 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: ditto blocks on ZFS
On Sat, 17 May 2014 13:50:52 Martin wrote: On 16/05/14 04:07, Russell Coker wrote: https://blogs.oracle.com/bill/entry/ditto_blocks_the_amazing_tape Probably most of you already know about this, but for those of you who haven't the above describes ZFS ditto blocks which is a good feature we need on BTRFS. The briefest summary is that on top of the RAID redundancy there... [... are additional copies of metadata ...] Is that idea not already implemented in effect in btrfs with the way that the superblocks are replicated multiple times, ever more times, for ever more huge storage devices? No. If the metadata for the root directory is corrupted then everything is lost even if the superblock is OK. At every level in the directory tree a corruption will lose all levels below that, a corruption for /home would be very significant as would a corruption of /home/importantuser/major-project. The one exception is for SSDs whereby there is the excuse that you cannot know whether your data is usefully replicated across different erase blocks on a single device, and SSDs are not 'that big' anyhow. I am not convinced by that argument. While you can't know that it's usefully replicated you also can't say for sure that replication will never save you. There will surely be some random factors involved. If dup on ssd will save you from 50% of corruption problems is it worth doing? What if it's 80% or 20%? I have BTRFS running as the root filesystem on Intel SSDs on four machines (one of which is a file server with a pair of large disks in a BTRFS RAID-1). On all of those systems I have dup for metadata, it doesn't take up any amount of space I need for something else and it might save me. So... Your idea of replicating metadata multiple times in proportion to assumed 'importance' or 'extent of impact if lost' is an interesting approach. However, is that appropriate and useful considering the real world failure mechanisms that are to be guarded against? Firstly it's not my idea, it's the idea of the ZFS developers. Secondly I started reading about this after doing some experiments with a failing SATA disk. In spite of having ~14,000 read errors (which sounds like a lot but is a small fraction of a 2TB disk) the vast majority of the data was readable, largely due to ~2000 errors corrected by dup metadata. Do you see or measure any real advantage? Imagine that you have a RAID-1 array where both disks get ~14,000 read errors. This could happen due to a design defect common to drives of a particular model or some shared environmental problem. Most errors would be corrected by RAID-1 but there would be a risk of some data being lost due to both copies being corrupt. Another possibility is that one disk could entirely die (although total disk death seems rare nowadays) and the other could have corruption. If metadata was duplicated in addition to being on both disks then the probability of data loss would be reduced. Another issue is the case where all drive slots are filled with active drives (a very common configuration). To replace a disk you have to physically remove the old disk before adding the new one. If the array is a RAID-1 or RAID-5 then ANY error during reconstruction loses data. Using dup for metadata on top of the RAID protections (IE the ZFS ditto idea) means that case doesn't lose you data. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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
Hang while deleting file
https://bugzilla.kernel.org/show_bug.cgi?id=76421 Perceived issue: SABNZBD hangs, requires restart. Diagnosis shows the following in my system log at the time of hang. This happens more than once. Log: [ 5883.464766] INFO: task SABnzbd.py:994 blocked for more than 120 seconds. [ 5883.464906] Not tainted 3.14.4-1-ARCH #1 [ 5883.464989] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 5883.465130] SABnzbd.py D 880196d1f5c0 0 994 1 0x [ 5883.465140] 8800765c9ce8 0082 0052 880196d1f5c0 [ 5883.465148] 000146c0 8800765c9fd8 000146c0 880196d1f5c0 [ 5883.465156] ffef 880177d9a000 a02d0dbc 8800765c9c50 [ 5883.465163] Call Trace: [ 5883.465218] [a02d0dbc] ? __set_extent_bit+0x45c/0x550 [btrfs] [ 5883.465252] [a02d03c3] ? free_extent_state+0x43/0xc0 [btrfs] [ 5883.465284] [a02d0dbc] ? __set_extent_bit+0x45c/0x550 [btrfs] [ 5883.465295] [810b3ba4] ? __wake_up+0x44/0x50 [ 5883.465304] [8150b729] schedule+0x29/0x70 [ 5883.465335] [a02d1cd2] lock_extent_bits+0x152/0x1e0 [btrfs] [ 5883.465344] [810b4020] ? __wake_up_sync+0x20/0x20 [ 5883.465375] [a02bfa59] btrfs_evict_inode+0x139/0x520 [btrfs] [ 5883.465387] [811d5a80] evict+0xb0/0x1c0 [ 5883.465394] [811d6335] iput+0xf5/0x1a0 [ 5883.465402] [811ca9c5] do_unlinkat+0x1b5/0x300 [ 5883.465411] [8117899c] ? vm_munmap+0x4c/0x60 [ 5883.465418] [811cb986] SyS_unlink+0x16/0x20 [ 5883.465427] [81517769] system_call_fastpath+0x16/0x1b Filesystem: # btrfs filesystem show Btrfs v3.14.1 running Data RAID, sys/meta RAID10 on 5x4TB. SABNzbd is a usenet download program, so the file attempting to be deleted was possibly large (GB) Recently updated to 3.14 kernel provided in arch linux. I haven't seen this issue before the last couple of days. Happy to provide more info if necessary. -- 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: Hang while deleting file
On May 18, 2014, at 10:36 AM, Joshua McKinney jos...@joshka.net wrote: https://bugzilla.kernel.org/show_bug.cgi?id=76421 Perceived issue: SABNZBD hangs, requires restart. Diagnosis shows the following in my system log at the time of hang. This happens more than once. Log: [ 5883.464766] INFO: task SABnzbd.py:994 blocked for more than 120 seconds. [ 5883.464906] Not tainted 3.14.4-1-ARCH #1 [ 5883.464989] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 5883.465130] SABnzbd.py D 880196d1f5c0 0 994 1 0x [ 5883.465140] 8800765c9ce8 0082 0052 880196d1f5c0 [ 5883.465148] 000146c0 8800765c9fd8 000146c0 880196d1f5c0 [ 5883.465156] ffef 880177d9a000 a02d0dbc 8800765c9c50 [ 5883.465163] Call Trace: [ 5883.465218] [a02d0dbc] ? __set_extent_bit+0x45c/0x550 [btrfs] [ 5883.465252] [a02d03c3] ? free_extent_state+0x43/0xc0 [btrfs] [ 5883.465284] [a02d0dbc] ? __set_extent_bit+0x45c/0x550 [btrfs] [ 5883.465295] [810b3ba4] ? __wake_up+0x44/0x50 [ 5883.465304] [8150b729] schedule+0x29/0x70 [ 5883.465335] [a02d1cd2] lock_extent_bits+0x152/0x1e0 [btrfs] [ 5883.465344] [810b4020] ? __wake_up_sync+0x20/0x20 [ 5883.465375] [a02bfa59] btrfs_evict_inode+0x139/0x520 [btrfs] [ 5883.465387] [811d5a80] evict+0xb0/0x1c0 [ 5883.465394] [811d6335] iput+0xf5/0x1a0 [ 5883.465402] [811ca9c5] do_unlinkat+0x1b5/0x300 [ 5883.465411] [8117899c] ? vm_munmap+0x4c/0x60 [ 5883.465418] [811cb986] SyS_unlink+0x16/0x20 [ 5883.465427] [81517769] system_call_fastpath+0x16/0x1b Filesystem: # btrfs filesystem show Btrfs v3.14.1 running Data RAID, sys/meta RAID10 on 5x4TB. SABNzbd is a usenet download program, so the file attempting to be deleted was possibly large (GB) Recently updated to 3.14 kernel provided in arch linux. I haven't seen this issue before the last couple of days. Happy to provide more info if necessary. I'd include as an attachment to the bug the output from sysrq-w. echo 1 /proc/sys/kernel/sysrq echo w /proc/sysrq-trigger dmesg https://www.kernel.org/doc/Documentation/sysrq.txt Chris Murphy-- 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: RAID-1 - suboptimal write performance?
On 2014/05/16 11:36 PM, Austin S Hemmelgarn wrote: On 05/16/2014 04:41 PM, Tomasz Chmielewski wrote: On Fri, 16 May 2014 14:06:24 -0400 Calvin Walton calvin.wal...@kepstin.ca wrote: No comment on the performance issue, other than to say that I've seen similar on RAID-10 before, I think. Also, what happens when the system crashes, and one drive has several hundred megabytes data more than the other one? This shouldn't be an issue as long as you occasionally run a scrub or balance. The scrub should find it and fix the missing data, and a balance would just rewrite it as proper RAID-1 as a matter of course. It's similar (writes to just one drive, while the other is idle) when removing (many) snapshots. Not sure if that's optimal behaviour. [snip] Ideally, BTRFS should dispatch the first write for a block in a round-robin fashion among available devices. This won't fix the underlying issue, but it will make it less of an issue for BTRFS. More ideally, btrfs should dispatch them in parallel. This will likely be looked into for N-way mirroring. Having 3 or more copies and working in the current way would be far from optimal. -- __ Brendan Hide http://swiftspirit.co.za/ http://www.webafrica.co.za/?AFF1E97 -- 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
What do the wait_current_trans messages mean I see on my raspberry pi?
Hi, Over the weekend I tried to copy one external usb drive (on ext4) to another one formatted with btrfs. Now I came back, and 48h later only ~300GB were copied and I found messages like the following on syslog: May 16 18:33:13 raspberrypi kernel: [ 8161.213142] btrfs-endio-wri D c0420f24 0 3593 2 0x May 16 18:33:13 raspberrypi kernel: [ 8161.213735] [c0420f24] (__schedule+0x288/0x568) from [bf24f488] (wait_current_trans+0xcc/0x13c [btrfs]) May 16 18:33:13 raspberrypi kernel: [ 8161.214357] [bf24f488] (wait_current_trans+0xcc/0x13c [btrfs]) from [bf250e68] (start_transaction+0x2d8/0x43c [btrfs]) May 16 18:33:13 raspberrypi kernel: [ 8161.214956] [bf250e68] (start_transaction+0x2d8/0x43c [btrfs]) from [bf2510c0] (btrfs_join_transaction+0x20/0x2c [btrfs]) May 16 18:33:13 raspberrypi kernel: [ 8161.215562] [bf2510c0] (btrfs_join_transaction+0x20/0x2c [btrfs]) from [bf25a334] (btrfs_finish_ordered_io+0x2c4/0x5b0 [btrfs]) May 16 18:33:13 raspberrypi kernel: [ 8161.216233] [bf25a334] (btrfs_finish_ordered_io+0x2c4/0x5b0 [btrfs]) from [bf28473c] (worker_loop+0x150/0x674 [btrfs]) May 16 18:33:13 raspberrypi kernel: [ 8161.216631] [bf28473c] (worker_loop+0x150/0x674 [btrfs]) from [c003a120] (kthread+0xa4/0xb0) May 16 18:33:13 raspberrypi kernel: [ 8161.218363] [c003a120] (kthread+0xa4/0xb0) from [c000e218] (ret_from_fork+0x14/0x3c) More of them are available at: http://pastebin.com/th9tuSas Any idea what they mean? Are they related to the slow speed I observed? Thank you in advance, Clemens -- 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
Help with crash on mount issue
I filed a bug for null pointer dereferences I started hitting: https://bugzilla.kernel.org/show_bug.cgi?id=76451 Noticing qgroup in the trace, I tried disabling/re-enabling quota support for the filesystem. That turned out to be a mistake. Now as soon as I mount, I'm getting an oops thanks to btrfs_qgroup_rescan_worker (see below). Is there any way to disable quota support for an unmounted filesystem? I'd also appreciate any help in troubleshooting the underlying corruption here. The corruption occurred on 3.14.1, and trying 3.15.0-rc5 still gives me the same crash on mount issues. Thanks for the help. --- May 18 17:09:26 gonzo kernel: BTRFS info (device dm-3): disk space caching is enabled May 18 17:09:36 gonzo kernel: BUG: unable to handle kernel NULL pointer dereference at 0004 May 18 17:09:36 gonzo kernel: IP: [c14698c0] ulist_next+0x10/0x40 May 18 17:09:36 gonzo kernel: *pdpt = *pde = f000eef3f000eef3 May 18 17:09:36 gonzo kernel: Oops: [#1] SMP May 18 17:09:36 gonzo kernel: Modules linked in: r8169 evdev May 18 17:09:36 gonzo kernel: CPU: 1 PID: 5086 Comm: btrfs-qgroup-re Not tainted 3.14.1 #1 May 18 17:09:36 gonzo kernel: Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77N-WIFI, BIOS F4 07/31/2013 May 18 17:09:36 gonzo kernel: task: f2afbc20 ti: ed8d6000 task.ti: ed8d6000 May 18 17:09:36 gonzo kernel: EIP: 0060:[c14698c0] EFLAGS: 00010292 CPU: 1 May 18 17:09:36 gonzo kernel: EIP is at ulist_next+0x10/0x40 May 18 17:09:36 gonzo kernel: EAX: EBX: 0004 ECX: 80240011 EDX: ed8d7e6c May 18 17:09:36 gonzo kernel: ESI: f26e4000 EDI: ed8d7f00 EBP: ed8d7e40 ESP: ed8d7e38 May 18 17:09:36 gonzo kernel: DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 May 18 17:09:36 gonzo kernel: CR0: 80050033 CR2: 0004 CR3: 01fc7000 CR4: 001407f0 May 18 17:09:36 gonzo kernel: Stack: May 18 17:09:36 gonzo kernel: f26e4000 ed8d7e7c c14685aa 0e4dc000 0a23 0001 May 18 17:09:36 gonzo kernel: f2827f50 f2827f60 f26e4000 ef68 eaccc950 0cd4 May 18 17:09:36 gonzo kernel: ed8d7f00 ed8d7f10 c146a740 0e4dc000 0a23 0001 ed8d7f00 May 18 17:09:36 gonzo kernel: Call Trace: May 18 17:09:36 gonzo kernel: [c14685aa] btrfs_find_all_roots+0x5a/0xf0 May 18 17:09:36 gonzo kernel: [c146a740] btrfs_qgroup_rescan_worker+0x2b0/0x660 May 18 17:09:36 gonzo kernel: [c143a496] worker_loop+0x76/0x3f0 May 18 17:09:36 gonzo kernel: [c10aab18] ? __wake_up_common+0x48/0x70 May 18 17:09:36 gonzo kernel: [c109341c] kthread+0xac/0xd0 May 18 17:09:36 gonzo kernel: [c143a420] ? btrfs_queue_worker+0x2c0/0x2c0 May 18 17:09:36 gonzo kernel: [c1b0c437] ret_from_kernel_thread+0x1b/0x28 May 18 17:09:36 gonzo kernel: [c1093370] ? __kthread_parkme+0x60/0x60 May 18 17:09:36 gonzo kernel: Code: 89 1c 24 e8 73 fe ff ff 8b 5d f8 8b 75 fc c9 c3 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 83 ec 08 89 1c 24 89 74 24 04 8d 58 04 8b 48 04 31 c0 39 cb 74 0b 8b 32 85 f6 75 11 89 0a 8d 41 f0 8b May 18 17:09:36 gonzo kernel: EIP: [c14698c0] ulist_next+0x10/0x40 SS:ESP 0068:ed8d7e38 May 18 17:09:36 gonzo kernel: CR2: 0004 May 18 17:09:36 gonzo kernel: ---[ end trace 45ab777217abb631 ]--- --- # btrfsck /dev/mapper/sda2-open Checking filesystem on /dev/mapper/sda2-open UUID: 8cb470e6-13ae-4e8a-aeef-e30942cc1072 checking extents checking free space cache checking fs roots checking csums checking root refs found 1165534378737 bytes used err is 0 total csum bytes: 2929733560 total tree bytes: 4212686848 total fs tree bytes: 766558208 total extent tree bytes: 282804224 btree space waste bytes: 369335816 file data blocks allocated: 3284956061696 referenced 3305002033152 Btrfs v3.14.1 -- 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
btrfs send ioctl failed with -5: Input/output error
I am now getting the following error when trying to do a btrfs send: root@maru2:/usr/local/src/btrfs-progs# ./btrfs send /usr/local/snapshots/2014-05-15 /backup/intermediate At subvol /usr/local/snapshots/2014-05-15 ERROR: send ioctl failed with -5: Input/output error I'm running a 3.14.4 kernel, and Btrfs progs v3.14.1. root@maru2:/usr/local/src/btrfs-progs# uname -a Linux maru2 3.14-1-amd64 #1 SMP Debian 3.14.4-1 (2014-05-13) x86_64 GNU/Linux root@maru2:/usr/local/src/btrfs-progs# ./btrfs --version Btrfs v3.14.1 Is there anything I can do to help debug this issue? -- Michael Welsh Duggan (m...@md5i.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
problem with degraded boot and systemd
Summary:
It's insufficient to pass rootflags=degraded to get the system root to mount
when a device is missing. It looks like when a device is missing, udev doesn't
create the dev-disk-by-uuid linkage that then causes systemd to change the
device state from dead to plugged. Only once plugged, will systemd attempt to
mount the volume. This issue was brought up on systemd-devel under the subject
timed out waiting for device dev-disk-by\x2duuid for those who want details.
Work around:
I tested systemd 208-16.fc20, and 212-4.fc21. Both will wait indefinitely for
dev-disk-by-x2uuid, and fail to drop to a dracut shell for a manual recovery
attempt. That seems like a bug to me so I filed that here:
https://bugzilla.redhat.com/show_bug.cgi?id=1096910
Therefore, first the system must be forced to shutdown, rebooted with boot
param rd.break=pre-mount to get to a dracut shell before the wait for root by
uuid begins. Then:
# mount -o subvol=root,ro,degraded device /sysroot
# exit
# exit
And then it boots normally. Fortunately btrfs fi show works so you can mount
with -U or with a non-missing /dev device.
What's going on:
Example of a 2 device Btrfs raid1 volume, using sda3 and sdb3.
Since boot parameter root=UUID= is used, systemd is expecting to issue the
mount command referencing that particular volume UUID. When all devices are
available, systemd-udevd produces entries like this for each device:
[2.168697] localhost.localdomain systemd-udevd[109]: creating link
'/dev/disk/by-uuid/9ff63135-ce42-4447-a6de-d7c9b4fb6d66' to '/dev/sda3'
[2.170232] localhost.localdomain systemd-udevd[135]: creating link
'/dev/disk/by-uuid/9ff63135-ce42-4447-a6de-d7c9b4fb6d66' to '/dev/sdb3'
But when just one device is missing, neither link is created by udev, and
that's the show stopper.
When all devices are present, the links are created, and systemd changes the
dev-disk-by-uuid device from dead to plugged like this:
[2.176280] localhost.localdomain systemd[1]:
dev-disk-by\x2duuid-9ff63135\x2dce42\x2d4447\x2da6de\x2dd7c9b4fb6d66.device
changed dead - plugged
And then systemd will initiate the command to mount it.
[2.177501] localhost.localdomain systemd[1]: Job
dev-disk-by\x2duuid-9ff63135\x2dce42\x2d4447\x2da6de\x2dd7c9b4fb6d66.device/start
finished, result=done
[2.586488] localhost.localdomain systemd[152]: Executing: /bin/mount
/dev/disk/by-uuid/9ff63135-ce42-4447-a6de-d7c9b4fb6d66 /sysroot -t auto -o
ro,ro,subvol=root
I think the key problem is either a limitation of udev, or a problem with the
existing udev rule, that prevents the link creation for any remaining btrfs
device. Or maybe it's intentional. But I'm not a udev expert. This is the
current udev rule:
# cat /usr/lib/udev/rules.d/64-btrfs.rules
# do not edit this file, it will be overwritten on update
SUBSYSTEM!=block, GOTO=btrfs_end
ACTION==remove, GOTO=btrfs_end
ENV{ID_FS_TYPE}!=btrfs, GOTO=btrfs_end
# let the kernel know about this btrfs filesystem, and check if it is complete
IMPORT{builtin}=btrfs ready $devnode
# mark the device as not ready to be used by the system
ENV{ID_BTRFS_READY}==0, ENV{SYSTEMD_READY}=0
LABEL=btrfs_end
How this works with raid:
RAID assembly is separate from filesystem mount. The volume UUID isn't
available until the RAID is successfully assembled.
On at least Fedora (dracut) systems with the system root on an md device, the
initramfs contains 30-parse-md.sh which includes a loop to check for the volume
UUID. If it's not found, the script sleeps for 0.5 seconds, and then looks for
it again, up to 240 times. If it's still not found at attempt 240, then the
script executes mdadm -R to forcibly run the array with fewer than all devices
present (degraded assembly). Now the volume UUID exists, udevd creates the
linkage, systemd picks this up and changes device state from dead to plugged,
and then executes a normal mount command.
The approximate Btrfs equivalent down the road would be a similar initrd
script, or maybe a user space daemon, that causes btrfs device ready to
confirm/deny all devices are present. And after x number of failures, then it's
issue an equivalent to mdadm -R which right now we don't seem to have.
That equivalent might be a decoupling of degraded as a mount option, such that
the user space tool deals with degradedness. And the mount command remains a
normal mount command (without degraded option). For example something like
btrfs filesystem allowdegraded -U uuid would cause some logic to
confirm/deny that degraded mounting is even possible, such as having the
minimum number of devices available. If it succeeds, then btrfs device ready
will report all devices are in fact present, enable udevd to create the links
by volume uuid, which then allows systemd to tigger a normal mount command.
Further, the btrfs allowdegraded command would set appropriate metadata on the
file system such that a normal mount command will succeed.
Or something
Re: send/receive and bedup
On Wed, May 14, 2014 at 11:36:03PM +0800, Scott Middleton wrote: I read so much about BtrFS that I mistaked Bedup with Duperemove. Duperemove is actually what I am testing. I'm currently using programs that find files that are the same, and hardlink them together: http://marc.merlins.org/perso/linux/post_2012-05-01_Handy-tip-to-save-on-inodes-and-disk-space_-finddupes_-fdupes_-and-hardlink_py.html hardlink.py actually seems to be the faster (memory and CPU) one event though it's in python. I can get others to run out of RAM on my 8GB server easily :( Bedup should be better, but last I tried I couldn't get it to work. It's been updated since then, I just haven't had the chance to try it again since then. Please post what you find out, or if you have a hardlink maker that's better than the ones I found :) Thanks, Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- 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: Can a snapshot become a parent subvolume when its parent is deleted?
On Wed, May 14, 2014 at 12:09:38PM -0600, Chris Murphy wrote: On May 14, 2014, at 7:50 AM, Marc MERLIN m...@merlins.org wrote: So, I had btrfs_pool1 that was trashed/lost as discussed here recently. I did btrfs send btrfs_pool2/root_ro.date | btrfs receive /mnt/btrfs_pool1 Then btrfs subvolume snapshot root_ro.date root Now, after I delete root_ro.date on btrfs_pool1, shouldn't root become a parent subvolume? There's no explicit hierarchy like this. There's no state parent or child. If a subvolume is created by snapshotting another subvolume, the new subvolume refers to the uuid of its source as the parent uuid. And the original subvolume, at least in the UI, contains a list of its snapshots but I don't know that this metadata is literally associated with the subvolume rather than inferred from its snapshots, all of which contain the parent subvolume's uuid as a parent_uuid. Right. So basically the parent UUID can go orphanned, which I found a bit surprising. Right now, I have: legolas:/mnt/btrfs_pool1# btrfs subvolume list -q . ID 390 gen 5954 top level 5 parent_uuid faea7df8-d51a-6b4b-994b-887d55267cce path root legolas:/mnt/btrfs_pool1# btrfs subvolume list -u . |grep faea7df8-d51a-6b4b-994b-887d55267cce legolas:/mnt/btrfs_pool1# Is it possible not to have a parent? If so, shouldn't you become a parent at that time? No. The listed subvolume parent_uuid is the subvolume uuid for now deleted subvolume root_ro.date. Even though it's deleted, the subvolume created from it still retains the parent_uuid reference. Yep. If you think about daemonized processed that get inherited by init, shouldn't parent-less snapshots change their parent uuid to '-' If you snapshot root, you could say it becomes a parent but it's only a metaphor it's not something that literally happens on disk. All I'm aware of that happens is the new subvolume gets its own uuid and its parent_uuid is set to match the subvolume uuid it was created from. You are correct. The blocks don't care who is the parent and child subvolume, they're just references. But for management purposes by us humans :) it's useful to know what's going on. Would a developer agree to making parent less subvolumes have their parent become '-'? Thanks, Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- 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 5/5] Btrfs: fix broken free space cache after the system crashed
On 01/15/2014 07:00 AM, Miao Xie wrote:
When we mounted the filesystem after the crash, we got the following
message:
BTRFS error (device xxx): block group 4315938816 has wrong amount of free
space
BTRFS error (device xxx): failed to load free space cache for block group
4315938816
It is because we didn't update the metadata of the allocated space until
the file data was written into the disk. During this time, there was no
information about the allocated spaces in either the extent tree nor the
free space cache. when we wrote out the free space cache at this time, those
spaces were lost.
In ordered to fix this problem, I use a state tree for every block group
to record those allocated spaces. We record the information when they are
allocated, and clean up the information after the metadata update. Besides
that, we also introduce a read-write semaphore to avoid the race between
the allocation and the free space cache write out.
Only data block groups had this problem, so the above change is just
for data space allocation.
I had this one in the integration branch, but lockdep reported troubles. It
looks like lockdep is correct. find_free_extent is nesting the cache rwsem
inside the groups rwsem, but btrfs_write_out_cache is holding the new cache
rwsem when it calls find_free_extent.
-chris
[ 2857.610731] ==
[ 2857.623158] [ INFO: possible circular locking dependency detected ]
[ 2857.635771] 3.15.0-rc5-mason+ #43 Not tainted
[ 2857.644553] ---
[ 2857.657139] btrfs-transacti/19476 is trying to acquire lock:
[ 2857.668518] (found-groups_sem){..}, at: [a059dbc1]
find_free_extent+0x931/0xe20 [btrfs]
[ 2857.687771]
[ 2857.687771] but task is already holding lock:
[ 2857.699566] (cache-data_rwsem){..}, at: [a05f78bf]
btrfs_write_out_cache+0x9f/0x170 [btrfs]
[ 2857.719480]
[ 2857.719480] which lock already depends on the new lock.
[ 2857.719480]
[ 2857.736021]
[ 2857.736021] the existing dependency chain (in reverse order) is:
[ 2857.751120]
- #1 (cache-data_rwsem){..}:
[ 2857.760823][810a14fe] lock_acquire+0x8e/0x110
[ 2857.772772][81649cf7] down_read+0x47/0x60
[ 2857.784028][a059db2c] find_free_extent+0x89c/0xe20 [btrfs]
[ 2857.798253][a059e11b] btrfs_reserve_extent+0x6b/0x140
[btrfs]
[ 2857.813041][a05b73ec] cow_file_range+0x13c/0x460 [btrfs]
[ 2857.826892][a05bc097] run_delalloc_range+0x347/0x380
[btrfs]
[ 2857.841510][a05d3f3d] __extent_writepage+0x70d/0x870
[btrfs]
[ 2857.856129][a05d456a]
extent_write_cache_pages.clone.6+0x30a/0x410 [btrfs]
[ 2857.873185][a05d46c2] extent_writepages+0x52/0x70 [btrfs]
[ 2857.887224][a05b3d57] btrfs_writepages+0x27/0x30 [btrfs]
[ 2857.901078][81142543] do_writepages+0x23/0x40
[ 2857.913034][81135b99] __filemap_fdatawrite_range+0x59/0x60
[ 2857.927240][81135dec] filemap_flush+0x1c/0x20
[ 2857.939215][a05b2502] btrfs_run_delalloc_work+0x72/0xa0
[btrfs]
[ 2857.954367][a05e05fe] normal_work_helper+0x6e/0x2d0 [btrfs]
[ 2857.968749][8106b9e2] process_one_work+0x1d2/0x550
[ 2857.981561][8106cd8f] worker_thread+0x11f/0x3a0
[ 2857.993856][8107317e] kthread+0xde/0x100
[ 2858.004936][8165436c] ret_from_fork+0x7c/0xb0
[ 2858.016887]
- #0 (found-groups_sem){..}:
[ 2858.026590][810a12de] __lock_acquire+0x161e/0x17b0
[ 2858.039407][810a14fe] lock_acquire+0x8e/0x110
[ 2858.051370][81649cf7] down_read+0x47/0x60
[ 2858.062629][a059dbc1] find_free_extent+0x931/0xe20 [btrfs]
[ 2858.076841][a059e11b] btrfs_reserve_extent+0x6b/0x140
[btrfs]
[ 2858.091629][a059e307] btrfs_alloc_free_block+0x117/0x420
[btrfs]
[ 2858.106940][a0589a5b] __btrfs_cow_block+0x11b/0x530 [btrfs]
[ 2858.121331][a058a4a0] btrfs_cow_block+0x130/0x1e0 [btrfs]
[ 2858.135375][a058c999] btrfs_search_slot+0x219/0x9c0 [btrfs]
[ 2858.149760][a05f7595] __btrfs_write_out_cache+0x755/0x970
[btrfs]
[ 2858.165245][a05f7958] btrfs_write_out_cache+0x138/0x170
[btrfs]
[ 2858.180411][a059ccb0]
btrfs_write_dirty_block_groups+0x480/0x600 [btrfs]
[ 2858.197107][a05ae7af] commit_cowonly_roots+0x19f/0x250
[btrfs]
[ 2858.212084][a05afbc0] btrfs_commit_transaction+0x450/0xa60
[btrfs]
[ 2858.227738][a05aa8a6] transaction_kthread+0x216/0x290
[btrfs]
[ 2858.242533][8107317e] kthread+0xde/0x100
[ 2858.253617][8165436c] ret_from_fork+0x7c/0xb0
[ 2858.265569]
[ 2858.265569] other info that might
Re: [PATCH 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand.
Original Message Subject: Re: [PATCH 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand. From: Hugo Mills h...@carfax.org.uk To: Qu Wenruo quwen...@cn.fujitsu.com Date: 2014年05月18日 20:05 On Sun, May 18, 2014 at 03:04:33PM +0800, Qu Wenruo wrote: Original Message Subject: Re: [PATCH 00/27] Replace the old man page with asciidoc and man page for each btrfs subcommand. From: Hugo Mills h...@carfax.org.uk To: dste...@suse.cz, Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org, c...@fb.com Date: 2014年05月18日 02:22 On Sat, May 17, 2014 at 06:43:15PM +0100, Hugo Mills wrote: On Wed, Apr 16, 2014 at 07:12:19PM +0200, David Sterba wrote: On Wed, Apr 02, 2014 at 04:29:11PM +0800, Qu Wenruo wrote: Convert the old btrfs man pages to new asciidoc and split the huge btrfs man page into subcommand man page. I'm merging this patchset into the base series of integration because several patches need to update the docs and it's no longer feasible to keep it in a separate branch from the patches. I've just been poking around in the docs for a completely different reason, and I think there's a fairly serious problem (well, as serious as problems get with documentation). Take, for example, the format for btrfs fi resize: 'resize' [devid:][+/-]size[gkm]|[devid:]max path:: Now, this has just thrown away all of the useful markup which indicates the semantics of the command. The asciidoc renders all of that text literally and unformatted, making alphasymbolic(*) soup of the docs. Compare this to the old roff man page: \fBbtrfs\fP \fBfilesystem resize\fP [\fIdevid\fP:][+/\-]\fIsize\fP[gkm]|[\fIdevid\fP:]\fImax path\fP This isn't perfect -- we're missing a \fB around the max -- but it has text in bold(⁑) and italics(⁂) and neither(☃). I've just looked at some of the other pages, and they've also got similar typographical problems. This is a lot of fiddly tedious work to get it right, and if it doesn't get done now in the initial commit, then we're going to end up with poor examples copied for every new feature or docs update, making the problem worse before anyone does the work to make it better. Oh, and asciidoc appears to be the most horrible capricious inconsistent parser in existence. I've just spent 5 minutes getting this one line of text to do what I want it to: = __N__**c**[\[_Mmin_**-**]__Mmax__**s**[_P_**p**]] = I had to run through the list of block quote operators one at a time in order to find the one I needed for this (the =); it's still not indenting it correctly on the resulting man page. Note also the fun things like the fact that [[]] is special, so you have to quote the opening part of it -- but if you try quoting the first [ with a \ you get a literal \[ in the output. You get the right output from quoting the *second* [ only. I have already encountered problems like that, especially when convert 'btrfs-resize' related things. But wait for a minute, do we really need the *fascinating* highlight things in a user documentation? Yes, absolutely. The formatting is a part of the _meaning_ of the documentation. Otherwise you're left guessing as to which pieces of the string of characters are meant to be there literally, and which pieces have to be replaced by suitable text, and which pieces are optional. The most important thing is the content not the format. My point is that in this case the formatting _is_ a part of the content. I choose asciidoc to make developers take less effort on the format things, not the opposite. In this point of view, I think asciidoc does things considerately well. Although the problem you mentioned is true, but it only affects a small part of the documentation, compared to the overall benefits, I still consider converting to asciidoc is worthy. I'm finding it almost impossible to make it do what I want. I think in some cases it actually _is_ impossible. This is a truly frustrating tool that is really not making things simpler, and I can see is going to lead to even more badly marked up documentation -- simply because it's too difficult and frustrating to get it right. The Nc can only be italicised and emboldened properly with __ and ** because _ and * require whitespace around them in order to work (seriously, WTF?). However, we can't be consistent with that in the _Mmin_**-** because the quoted \[ appears to count as whitespace, so using __Mmin__ gives us a leading literal _. The closing __ appears to close the single opening _ correctly in that case, though. Seriously, this is meant to be _easy_ to use? I think I'd rather type docbook by hand that have to struggle with this. Even the troff macros for man pages are simpler to get right. From the purpose of documentation and the above explaination, I think the answer is *Yes*. Only if you don't care about the typography of the resulting document. Since you
Re: [PATCH 2/3] btrfs-progs: add missing help option for rescue super-recover
On Fri, 2014-05-16 at 18:41 +0200, David Sterba wrote: On Fri, May 16, 2014 at 06:37:27PM +0200, David Sterba wrote: On Thu, May 15, 2014 at 09:29:08AM +0800, Gui Hecheng wrote: Add '-h' option for help for super-recover, update the manpage at the same time. We don't have the short option for help, a few patches have been already rejected to change that. Reference: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg30759.html Yes, I get it. Thanks David. -- 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
[PATCH] btrfs-image: Fix a data race in build_chunk_tree.
A mdrestore_struct was being written to without its mutex being held. This race was found with ThreadSanitizer; the relevant part of the report looks like this: WARNING: ThreadSanitizer: data race (pid=18828) Write of size 8 at 0x7fc3d088 by main thread: #0 build_chunk_tree .../btrfs-progs/btrfs-image.c:2233 #1 __restore_metadump .../btrfs-progs/btrfs-image.c:2294 #2 restore_metadump .../btrfs-progs/btrfs-image.c:2345 #3 main .../btrfs-progs/btrfs-image.c:2545 Previous read of size 8 at 0x7fc3d088 by thread T1 (mutexes: write M0): #0 restore_worker .../btrfs-progs/btrfs-image.c:1636 Location is stack of main thread. Mutex M0 created at: #0 pthread_mutex_init ??:0 #1 mdrestore_init .../btrfs-progs/btrfs-image.c:1766 #2 __restore_metadump .../btrfs-progs/btrfs-image.c:2286 #3 restore_metadump .../btrfs-progs/btrfs-image.c:2345 #4 main .../btrfs-progs/btrfs-image.c:2545 Thread T1 (tid=18830, running) created by main thread at: #0 pthread_create ??:0 #1 mdrestore_init .../btrfs-progs/btrfs-image.c:1784 #2 __restore_metadump .../btrfs-progs/btrfs-image.c:2286 #3 restore_metadump .../btrfs-progs/btrfs-image.c:2345 #4 main .../btrfs-progs/btrfs-image.c:2545 --- btrfs-image.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/btrfs-image.c b/btrfs-image.c index cc8627c..017ab1d 100644 --- a/btrfs-image.c +++ b/btrfs-image.c @@ -2228,6 +2228,7 @@ static int build_chunk_tree(struct mdrestore_struct *mdres, buffer = tmp; } + pthread_mutex_lock(mdres-mutex); super = (struct btrfs_super_block *)buffer; chunk_root_bytenr = btrfs_super_chunk_root(super); mdres-leafsize = btrfs_super_leafsize(super); @@ -2236,6 +2237,7 @@ static int build_chunk_tree(struct mdrestore_struct *mdres, BTRFS_UUID_SIZE); mdres-devid = le64_to_cpu(super-dev_item.devid); free(buffer); + pthread_mutex_unlock(mdres-mutex); return search_for_chunk_blocks(mdres, chunk_root_bytenr, 0); } -- 1.9.1.423.g4596e3a -- 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
