Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk
Hey Qu.
On Sun, 2015-11-22 at 10:04 +0800, Qu Wenruo wrote:
> If any of you can recompile btrfs-progs and use gdb to debug it,
> would
> anyone please to investigate where did the wrong_chunk_type is set?
> It is in the function check_extent_type():
Not 100% what you want... AFAIU, you just want to see whether that line
is reached?
If didn't re-compile but used the btrfs-tools-dbg package, but I guess
that should do.
In the debian version that line seems to be at:
4374
4375 /* Check if the type of extent matches with its chunk */
4376 static void check_extent_type(struct extent_record *rec)
4377 {
...
4419 bg_type = BTRFS_BLOCK_GROUP_METADATA;
4420 if (!(bg_cache->flags & bg_type))
4421 rec->wrong_chunk_type = 1;
4422 }
4423 }
Running:
# gdb btrfs
(gdb) dir /root/btrfs-tools-4.3
Source directories searched: /root/btrfs-tools-4.3:$cdir:$cwd
(gdb) break cmds-check.c:4421
Breakpoint 1 at 0x41d859: file cmds-check.c, line 4421.
(gdb) run check /dev/mapper/data-b
Starting program: /bin/btrfs check /dev/mapper/data-b
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
... in fact reaches that breakpoint:
Breakpoint 1, check_extent_type (rec=rec@entry=0x884290) at cmds-check.c:4423
4423}
... but the error message ("bad extent [5993525264384, 5993525280768),
type mismatch with chunk") doesn't seem to be printed at that stage...
If I continue, it goes for a while:
Breakpoint 1, check_extent_type (rec=rec@entry=0x884290) at cmds-check.c:4423
4423}
(gdb) cont 10
Will ignore next 9 crossings of breakpoint 1. Continuing.
and so on for at least several million crossings... I then removed the
breakpoint and after a longer while the usual error messages came up.
Does that help?
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Re: free space is missing after dist upgrade on lzo compressed vol
Brenton Chapin posted on Sat, 21 Nov 2015 12:32:12 -0600 as excerpted: > Thanks, snapshots, or subvolumes, was it. (I'm not clear on the > distinction between a snapshot and a subvolume.) As Hugo says much more briefly, snapshots are a special kind of subvolume. These are normally (copy-on-write, aka cow, based) "snapshots" of another subvolume at a the point they were taken, containing the same data, etc. Snapshots can be read-only, in which case they lock in what the snapshotted subvolume looked like at that time, or writable, just like normal subvolumes, in which case they start out looking like the subvolume they snapshotted at that point in time, but both the original subvolume and its writable snapshot can be written to, so one or both can diverge from the "picture" that was taken by the snapshot. Subvolumes (and thus snapshots, since snapshots are a special case of subvolume), meanwhile, look and work almost like directories, except they have a few extra features that normal directories don't have, the biggest of which is that subvolumes can be mounted separately, as if they were their own filesystems. This is actually what's happening below, as it's not the "root" subvolume that's actually mounted at /, but rather, a subvolume below the root subvolume. Knowing that should help make sense of the subvolume list output, below, and explains why you don't see the subvolumes in the filesystem, as what's mounted at / isn't actually the root subvolume, but a subvolume nested within the root subvolume. More on that below, but while we're talking about subvolume features, let me repeat something I said above, now that you have a bit more context to put it in. Snapshots are taken of specific subvolumes (again, if it helps, think subdirs), NOT of the whole filesystem including all subvolumes. As such, snapshots stop at subvolume boundaries. If for instance you take a snapshot of the root subvolume (ID 5 in the listing below, *NOT* the nested subvolume below it that happens to be mounted at /), you get a picture/snapshot of only what's directly in it, not what's in subvolumes nested beneath it. Nested subvolumes are snapshotted separately. > btrfs subvolume list -p / > ID 257 gen 16615 parent 5 top level 5 path @ > ID 262 gen 15857 parent 5 top level 5 path > @apt-snapshot-release-upgrade-vivid-2015-11-12_15:49:30 > ID 266 gen 16544 parent 257 top level 257 path > var/lib/machines > ID 268 gen 16203 parent 5 top level 5 path > @apt-snapshot-release-upgrade-wily-2015-11-13_04:10:00 > > Seems these subvolumes (snapshots?) are nowhere visible in the file > system. Now I'm trying to figure out the correct commands to delete > them. "btrfs subvolume delete @apt-snapshot..." gave "ERROR: error > accessing '@apt-snapshot...", while "btrfs sbuvolume show " on > variations of the name keep giving me "ERROR: finding real path for > '...', No such file or directory." No luck so far. What am I missing? As I said above, you won't see these subvolumes (including snapshots) visible in the filesystem, because what you have mounted at / is not the root level (ID 5) subvolume, but rather, a subvolume nested within it. Visualizing the above listing as a tree, you have... +-+-- ID 5 root subvolume, always ID 5 (not listed) | +-+-- ID 257 @ (this is what is mounted at /) | | | +-- ID 266(@/)var/lib/machines (systemd generated) | +-- ID 262 @apt-snapshot-release-upgrade-vivid... | +-- ID 268 @apt-snapshot-release-upgrade-wily... As mentioned, it's ID 257, @, that's mounted at /. Your 4.2 kernel is actually new enough to print this information in the mount output, and indeed, from the mount output you posted upthread: > /dev/sda6 on / type btrfs > (rw,relatime,compress=lzo,space_cache,subvolid=257,subvol=/@) See that subvolid=257,subvol=/@ ? That's the same ID 257 @ as shown in your subvolume list, and as I diagrammed in the tree layout. IDs 262 and 268 are snapshots of the state of ID 257 @, at the time you did the upgrades. ID 5 is of course the root subvolume, in which the others are nested, and ID 257 @, has ID 266 nested within it. Of course this information can be easily seen from the tree layout I did, but it's there in the listing as well, with the parent/top-level ID in the listing being the direct parent subvolume. OK, so how do you delete those snapshots and recover the space they claim? As with normal directories in filesystems, to work with subvolumes/ snapshots in btrfs, you need a subvolume from which they're descended mounted. Since ID 257 (@) is mounted, ID 266, var/lib/machines, nested within it, is visible in its tree, and for most purposes will look and behave like an ordinary directory, except that you won't be able to rmdir it, because it's actually a subvolume. As long as it's not actually mounted as its own subvolume, however, you could btrfs subvolume delete it, if you wanted to. Bu
Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk
Hi Lukas, Laurent and Christoph,
If any of you can recompile btrfs-progs and use gdb to debug it, would
anyone please to investigate where did the wrong_chunk_type is set?
It is in the function check_extent_type():
--
/* Check if the type of extent matches with its chunk */
static void check_extent_type(struct extent_record *rec)
{
struct btrfs_block_group_cache *bg_cache;
bg_cache = btrfs_lookup_first_block_group(global_info, rec->start);
if (!bg_cache)
return;
/* data extent, check chunk directly*/
if (!rec->metadata) {
if (!(bg_cache->flags & BTRFS_BLOCK_GROUP_DATA))
rec->wrong_chunk_type = 1; <<< HERE
return;
}
/* metadata extent, check the obvious case first */
if (!(bg_cache->flags & (BTRFS_BLOCK_GROUP_SYSTEM |
BTRFS_BLOCK_GROUP_METADATA))) {
rec->wrong_chunk_type = 1; <<< HERE
return;
}
/*
* Check SYSTEM extent, as it's also marked as metadata, we can only
* make sure it's a SYSTEM extent by its backref
*/
if (!list_empty(&rec->backrefs)) {
struct extent_backref *node;
struct tree_backref *tback;
u64 bg_type;
node = list_entry(rec->backrefs.next, struct extent_backref,
list);
if (node->is_data) {
/* tree block shouldn't have data backref */
rec->wrong_chunk_type = 1; <<< HERE
return;
}
tback = container_of(node, struct tree_backref, node);
if (tback->root == BTRFS_CHUNK_TREE_OBJECTID)
bg_type = BTRFS_BLOCK_GROUP_SYSTEM;
else
bg_type = BTRFS_BLOCK_GROUP_METADATA;
if (!(bg_cache->flags & bg_type))
rec->wrong_chunk_type = 1; <<< HERE
}
}
--
If you can add break point on the "rec->wrong_chunk_type = 1;" line, it
would be quite helpful for further debugging.
Thanks,
Qu
On 11/21/2015 09:08 AM, Lukas Pirl wrote:
On 11/21/2015 01:47 PM, Qu Wenruo wrote as excerpted:
Hard to say, but we'd better keep an eye on this issue.
At least, if it happens again, we should know if it's related to
something like newer kernel or snapshots.
I can confirm the initially describe behavior of "btrfs check" and
reading the data works fine also.
Versions etc.:
$ uname -a
Linux 4.2.0-0.bpo.1-amd64 #1 SMP Debian 4.2.6-1~bpo8+1 …
$ btrfs filesystem show /mnt/data
Label: none uuid: 5be372f5-5492-4f4b-b641-c14f4ad8ae23
Total devices 6 FS bytes used 2.87TiB
devid1 size 931.51GiB used 636.00GiB path /dev/mapper/…SZ
devid2 size 931.51GiB used 634.03GiB path /dev/mapper/…03
devid3 size 1.82TiB used 1.53TiB path /dev/mapper/…76
devid4 size 1.82TiB used 1.53TiB path /dev/mapper/…78
devid6 size 1.82TiB used 1.05TiB path /dev/mapper/…UK
*** Some devices missing
btrfs-progs v4.3
$ btrfs subvolume list /mnt/data | wc -l
62
Best,
Lukas
--
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
--
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: free space is missing after dist upgrade on lzo compressed vol
On Sat, Nov 21, 2015 at 12:32:12PM -0600, Brenton Chapin wrote: > Thanks, snapshots, or subvolumes, was it. (I'm not clear on the > distinction between a snapshot and a subvolume.) A snapshot is just a subvolume that's initialised (via CoW copies) with the contents of some other subvolume, rather than starting empty. Hugo. > The 8G amount and > that I did 2 distribution upgrades was a clue. When I searched for > info on btrfs and snapshots, I eventually found this command, with > these results: > > btrfs subvolume list -p / > ID 257 gen 16615 parent 5 top level 5 path @ > ID 262 gen 15857 parent 5 top level 5 path > @apt-snapshot-release-upgrade-vivid-2015-11-12_15:49:30 > ID 266 gen 16544 parent 257 top level 257 path var/lib/machines > ID 268 gen 16203 parent 5 top level 5 path > @apt-snapshot-release-upgrade-wily-2015-11-13_04:10:00 > > Seems these subvolumes (snapshots?) are nowhere visible in the file > system. Now I'm trying to figure out the correct commands to delete > them. "btrfs subvolume delete @apt-snapshot..." gave "ERROR: error > accessing '@apt-snapshot...", while "btrfs sbuvolume show " on > variations of the name keep giving me "ERROR: finding real path for > '...', No such file or directory." No luck so far. What am I > missing? > > On Sat, Nov 14, 2015 at 3:16 AM, Timofey Titovets > wrote: > > Ubuntu create snapshot before each release upgrade > > sudo mount /dev/sda6 /mnt -o rw,subvol=/; > > ls /mnt > > > > 2015-11-14 9:16 GMT+03:00 Brenton Chapin : > >> Thanks for the ideas. Sadly, no snapshots, unless btrfs does that by > >> default. Never heard of snapper before. > >> > >> Don't see how open files could be a problem, since the computer has > >> been rebooted several times. > >> > >> I wonder... could the distribution upgrade have moved all the old > >> files into a hidden trash directory, rather than deleting them? But > >> du picks up hidden directories, I believe. Doesn't seem like that > >> could be it either. > >> > >> On Fri, Nov 13, 2015 at 4:38 PM, Hugo Mills wrote: > >>> On Fri, Nov 13, 2015 at 04:33:23PM -0600, Brenton Chapin wrote: > I was running Lubuntu 14.04 on btrfs with lzo compresssion on, with > the following partition scheme: > > sda5 232M /boot > sda6 16G / > sda7 104G /home > > (sda5 is ext4) > > I did 2 distribution upgrades, one after the other, to 15.04, then > 15.10, since the upgrade utility would not go directly to the latest > version. This process did a whole lot of reading and writing to the > root volume of course. Everything seems to be working, except most of > the free space I had on sda6 is gone. Was using about 4G, now df > reports that the usage is 12G. At first, I thought Lubuntu had not > removed old files, but I can't find anything old left behind. I began > to suspect btrfs, and checking, find that du shows only 4G used on > sda6. Where'd the other 8G go? > >>> > >>>Do you have snapshots? Are you running snapper, for example? > >>> > >>>The other place that large amounts of space can go over an upgrade > >>> is in orphans -- files that are deleted, but still held open by > >>> processes, and which therefore can't be reclaimed until the process is > >>> restarted. I've been bitten by that one before. > >>> > >>>Hugo. > >>> > "btrfs fi df /" reports the following: > > Data, single: total=11.01GiB, used=10.58GiB > System, DUP: total=8.00MiB, used=16.00KiB > System, single: total=4.00MiB, used=0.00B > Metadata, DUP: total=1.00GiB, used=397.80MiB > Metadata, single: total=8.00MiB, used=0.00B > GlobalReserve, single: total=144.00MiB, used=0.00B > > "btrfs filesystem show /" gives: > > Label: none uuid: 4ea4ac08-ff37-4b51-b1a3-d8b21fd43ddd > Total devices 1 FS bytes used 10.97GiB > devid1 size 15.02GiB used 13.04GiB path /dev/sda6 > > btrfs-progs v4.0 > > "du --max-depth=1 -h -x" on / shows: > > 29M./etc > 0./media > 16M./bin > 354M./lib > 4.0K./lib64 > 0./mnt > 160K./root > 12M./sbin > 0./srv > 4.0K./tmp > 3.1G./usr > 442M./var > 0./cdrom > 3.8M./lib32 > 3.9G. > > And of course df: > > /dev/sda616G 12G 2.5G 83% / > /dev/sda5 232M 53M 163M 25% /boot > /dev/sda7 104G 46G 57G 45% /home > > And mount: > > mount |grep sda > /dev/sda6 on / type btrfs > (rw,relatime,compress=lzo,space_cache,subvolid=257,subvol=/@) > /dev/sda5 on /boot type ext4 (rw,relatime,data=ordered) > /dev/sda7 on /home type btrfs > (rw,relatime,compress=lzo,space_cache,subvolid=257,subvol=/@home) > > uname -a > Linux ichor 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC >
Re: free space is missing after dist upgrade on lzo compressed vol
Thanks, snapshots, or subvolumes, was it. (I'm not clear on the distinction between a snapshot and a subvolume.) The 8G amount and that I did 2 distribution upgrades was a clue. When I searched for info on btrfs and snapshots, I eventually found this command, with these results: btrfs subvolume list -p / ID 257 gen 16615 parent 5 top level 5 path @ ID 262 gen 15857 parent 5 top level 5 path @apt-snapshot-release-upgrade-vivid-2015-11-12_15:49:30 ID 266 gen 16544 parent 257 top level 257 path var/lib/machines ID 268 gen 16203 parent 5 top level 5 path @apt-snapshot-release-upgrade-wily-2015-11-13_04:10:00 Seems these subvolumes (snapshots?) are nowhere visible in the file system. Now I'm trying to figure out the correct commands to delete them. "btrfs subvolume delete @apt-snapshot..." gave "ERROR: error accessing '@apt-snapshot...", while "btrfs sbuvolume show " on variations of the name keep giving me "ERROR: finding real path for '...', No such file or directory." No luck so far. What am I missing? On Sat, Nov 14, 2015 at 3:16 AM, Timofey Titovets wrote: > Ubuntu create snapshot before each release upgrade > sudo mount /dev/sda6 /mnt -o rw,subvol=/; > ls /mnt > > 2015-11-14 9:16 GMT+03:00 Brenton Chapin : >> Thanks for the ideas. Sadly, no snapshots, unless btrfs does that by >> default. Never heard of snapper before. >> >> Don't see how open files could be a problem, since the computer has >> been rebooted several times. >> >> I wonder... could the distribution upgrade have moved all the old >> files into a hidden trash directory, rather than deleting them? But >> du picks up hidden directories, I believe. Doesn't seem like that >> could be it either. >> >> On Fri, Nov 13, 2015 at 4:38 PM, Hugo Mills wrote: >>> On Fri, Nov 13, 2015 at 04:33:23PM -0600, Brenton Chapin wrote: I was running Lubuntu 14.04 on btrfs with lzo compresssion on, with the following partition scheme: sda5 232M /boot sda6 16G / sda7 104G /home (sda5 is ext4) I did 2 distribution upgrades, one after the other, to 15.04, then 15.10, since the upgrade utility would not go directly to the latest version. This process did a whole lot of reading and writing to the root volume of course. Everything seems to be working, except most of the free space I had on sda6 is gone. Was using about 4G, now df reports that the usage is 12G. At first, I thought Lubuntu had not removed old files, but I can't find anything old left behind. I began to suspect btrfs, and checking, find that du shows only 4G used on sda6. Where'd the other 8G go? >>> >>>Do you have snapshots? Are you running snapper, for example? >>> >>>The other place that large amounts of space can go over an upgrade >>> is in orphans -- files that are deleted, but still held open by >>> processes, and which therefore can't be reclaimed until the process is >>> restarted. I've been bitten by that one before. >>> >>>Hugo. >>> "btrfs fi df /" reports the following: Data, single: total=11.01GiB, used=10.58GiB System, DUP: total=8.00MiB, used=16.00KiB System, single: total=4.00MiB, used=0.00B Metadata, DUP: total=1.00GiB, used=397.80MiB Metadata, single: total=8.00MiB, used=0.00B GlobalReserve, single: total=144.00MiB, used=0.00B "btrfs filesystem show /" gives: Label: none uuid: 4ea4ac08-ff37-4b51-b1a3-d8b21fd43ddd Total devices 1 FS bytes used 10.97GiB devid1 size 15.02GiB used 13.04GiB path /dev/sda6 btrfs-progs v4.0 "du --max-depth=1 -h -x" on / shows: 29M./etc 0./media 16M./bin 354M./lib 4.0K./lib64 0./mnt 160K./root 12M./sbin 0./srv 4.0K./tmp 3.1G./usr 442M./var 0./cdrom 3.8M./lib32 3.9G. And of course df: /dev/sda616G 12G 2.5G 83% / /dev/sda5 232M 53M 163M 25% /boot /dev/sda7 104G 46G 57G 45% /home And mount: mount |grep sda /dev/sda6 on / type btrfs (rw,relatime,compress=lzo,space_cache,subvolid=257,subvol=/@) /dev/sda5 on /boot type ext4 (rw,relatime,data=ordered) /dev/sda7 on /home type btrfs (rw,relatime,compress=lzo,space_cache,subvolid=257,subvol=/@home) uname -a Linux ichor 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux I can live with the situation, but recovering that space would be nice. >>> >>> -- >>> Hugo Mills | Happiness is mandatory. Are you happy? >>> hugo@... carfax.org.uk | >>> http://carfax.org.uk/ | >>> PGP: E2AB1DE4 | >>> Paranoia >> >> >> >> -- >> http://brentonchapin.no-ip.biz >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-b
Re: [PATCH 2/2] generic/15[78]: fix error messages in the golden output
> Shouldn't these be Invalid argument just like the > to a device case above or the clone case? E.g. something like this on top of your patch: diff --git a/tests/generic/158.out b/tests/generic/158.out index 1210429..dff3692 100644 --- a/tests/generic/158.out +++ b/tests/generic/158.out @@ -16,9 +16,9 @@ XFS_IOC_FILE_EXTENT_SAME: Invalid argument Try to dedupe to a dir TEST_DIR/test-158/dir1: Is a directory Try to dedupe to a device -dedupe: Operation not supported +dedupe: Invalid argument Try to dedupe to a fifo -dedupe: Operation not supported +dedupe: Invalid argument Try to dedupe an append-only file Dedupe two files Check scratch fs -- 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 2/2] generic/15[78]: fix error messages in the golden output
> --- a/tests/generic/158.out > +++ b/tests/generic/158.out > Try to dedupe a device > -XFS_IOC_FILE_EXTENT_SAME: Permission denied > +XFS_IOC_FILE_EXTENT_SAME: Invalid argument > Try to dedupe to a dir > -/mnt/test-158/dir1: Is a directory > +TEST_DIR/test-158/dir1: Is a directory > Try to dedupe to a device > -dedupe: Permission denied > +dedupe: Operation not supported > Try to dedupe to a fifo > -dedupe: Permission denied > +dedupe: Operation not supported Shouldn't these be Invalid argument just like the to a device case above or the clone case? Otherwise looks good, Reviewed-by: Christoph Hellwig -- 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.2.6: livelock in recovery (free_reloc_roots)?
On 11/21/2015 08:16 PM, Duncan wrote as excerpted: > Lukas Pirl posted on Sat, 21 Nov 2015 13:37:37 +1300 as excerpted: > >> > Can "btrfs_recover_relocation" prevented from being run? I would not >> > mind losing a few recent writes (what was a balance) but instead going >> > rw again, so I can restart a balance. > I'm not familiar with that thread name (I run multiple small btrfs on > ssds, so scrub, balance, etc, take only a few minutes at most), but if First, thank you Duncan for taking the time to hack in those broad explanations. I am not sure if this name also corresponds to a thread name, but it is for sure a function that appears in all the dumped traces when trying to 'mount -o recovery,degraded' the file system in question: [] ? free_reloc_roots+0x1d/0x30 [btrfs] [] ? merge_reloc_roots+0x165/0x220 [btrfs] [] ? btrfs_recover_relocation+0x293/0x380 [btrfs] [] ? open_ctree+0x20d2/0x23b0 [btrfs] [] ? btrfs_mount+0x87b/0x990 [btrfs] > it's the balance thread, then yes, there's a mount option that cancels a > running balance. See the wiki page covering mount options. Yes, the file system is mounted with '-o skip_balance'. (Although the '-o recovery' might trigger relocations?!) >> > From what I have read, btrfs-zero-log would not help in this case (?) so >> > I did not run it so far. > Correct. Btrfs is atomic at commit time, so doesn't need a journal in > the sense of older filesystems like reiserfs, jfs and ext3/4. > … > Otherwise, it generally does no good, and while > it generally does no serious harm beyond the loss of a few seconds worth > of fsyncs, etc, either, because the commits /are/ atomic and zeroing the > log simply returns the system to the state of such a commit, it's not > recommended as it /does/ needlessly kill the log of those last few > seconds of fsyncs. So I see that it does no good but no serious harm (generally). Since it is related to writes (not relocations, I assume) clearing the log is unlikely to fix the problem with btrfs_recover_relocation or merge_reloc_roots, respectively. Maybe a dev helps us and shines some light in the (I assume) impossible relocation issue. Best, Lukas -- 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.2.6: livelock in recovery (free_reloc_roots)?
Den 2015-11-21 kl. 08:16, skrev Duncan: > Lukas Pirl posted on Sat, 21 Nov 2015 13:37:37 +1300 as excerpted: > >> Can "btrfs_recover_relocation" prevented from being run? I would not >> mind losing a few recent writes (what was a balance) but instead going >> rw again, so I can restart a balance. > > I'm not familiar with that thread name (I run multiple small btrfs on > ssds, so scrub, balance, etc, take only a few minutes at most), but if > it's the balance thread, then yes, there's a mount option that cancels a > running balance. See the wiki page covering mount options. > >> From what I have read, btrfs-zero-log would not help in this case (?) so >> I did not run it so far. > > Correct. Btrfs is atomic at commit time, so doesn't need a journal in > the sense of older filesystems like reiserfs, jfs and ext3/4. > > What's this log, then? While btrfs won't fully write normal file writes > until a commit (every 30 seconds by default, there's a mount option...), > which is atomic (with copy-on-write helping here) so in the event of a > crash either the before or after state is returned, not something half > written, fsync is different. That says don't return until the file is > written to storage. But if a commit is done to ensure that, there may be > far more data to commit that otherwise doesn't need to be committed yet, > seriously slowing things down. So that's where this log comes in. It's > purely a log of fsynced data (and perhaps a few other similar things, I'm > not a dev and am not sure) between atomic commits, so the fsync can > return quickly while still having actually written the data to store, > without having to wait upto 30 seconds (by default) for the normal commit > to complete, or forcing a commit, along with everything else half > written, early. > > There was a bug at one point where this log could be corrupted and thus > couldn't be written properly at mount, but the primary trigger bug for > that problem is long since fixed, so while there's various hardware bugs > and etc that could still by remote chance cause problems, thus the option > to zero the log, it's a very rare occurrence, and the trace when it fails > is telltale enough that if it's posted the devs can tell you to run the > zero-log command then. Otherwise, it generally does no good, and while > it generally does no serious harm beyond the loss of a few seconds worth > of fsyncs, etc, either, because the commits /are/ atomic and zeroing the > log simply returns the system to the state of such a commit, it's not > recommended as it /does/ needlessly kill the log of those last few > seconds of fsyncs. > >> By the way, I can confirm the defect of 'btrfs device remove missing …" >> mentioned here: http://www.spinics.net/lists/linux-btrfs/msg48383.html : >> >> $ btrfs device delete missing >> /mnt/data ERROR: missing is not a block device >> $ btrfs device delete 5 >> /mnt/data ERROR: 5 is not a block device > > That's a known bug, with patches working their way thru the system both > to provide a different alternative and to let btrfs device delete missing > work again, but IDR the specific status of those patches. Presumably > they'll be in 4.4, but I don't know if they made it into 4.3 or not and > don't feel like looking it up ATM when you could do so just as easily. This is fixed in btrfs-progs 4.3.1, that allows you to delete a device again by the 'missing' keyword. -- Best regards, Alexander Fougner -- 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
