Re: How to get Super_num_devices in sync with num_devices again?!
He Guys! Again now in a readable from I have an Ubuntu 16.04 machine (K4.4 and K4.11, btrfs-progs v4.5.2) running / on btrfs raid1 and for some month (after i had to replace a / disk) super_numdevices and num_devices are out of sync peventing me to boot Kernels newer than around 4.7 (afaik), where the kernels began the be more restictive on checking valid btrfs disks. I tried to remove the raid and converted to single with several balances after that so that there are no raid chunks left. Label: 'System' uuid: 35fdbfd4-5809-4a30-94c1-5e3ca206ca4d Total devices 1 FS bytes used 14.86GiB devid6 size 50.00GiB used 17.31GiB path /dev/nvme0n1p1 Data, single: total=15.00GiB, used=13.84GiB System, single: total=64.00MiB, used=16.00KiB Metadata, single: total=2.25GiB, used=1.02GiB GlobalReserve, single: total=336.00MiB, used=0.00B /dev/nvme0n1p1, ID: 6 Device size:50.00GiB Data,single:15.00GiB Metadata,single: 2.25GiB System,single: 64.00MiB Unallocated:32.69GiB Overall: Device size: 50.00GiB Device allocated: 17.31GiB Device unallocated: 32.69GiB Device missing: 0.00B Used: 14.86GiB Free (estimated): 33.85GiB(min: 33.85GiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 336.00MiB(used: 0.00B) Data,single: Size:15.00GiB, Used:13.84GiB /dev/nvme0n1p1 15.00GiB Metadata,single: Size:2.25GiB, Used:1.02GiB /dev/nvme0n1p1 2.25GiB System,single: Size:64.00MiB, Used:16.00KiB /dev/nvme0n1p1 64.00MiB Unallocated: /dev/nvme0n1p1 32.69GiB But again newer kernels refuse to boot with tlling me: "BTRFS error.: super_num_devices 2 missmatch with num_devices 1 found here". So the the two counters are alwasy off by one, dont matter what i try. Question: how do i get thouse two counters in sync again so that my system acts again as expected?! regards Sash Am 05.10.2017 um 13:38 schrieb g6094...@freenet.de: He Guys!I have an ubuntu 16.04 machine (K4.4 and K4.11, btrfs-progs v4.5.2) running / on btrfs raid1 and for somemonth (after i had to replace a / disk) super_numdevices and num_devices are out of sync peventing me to bootKernels newer than around 4.7 (ifaik), where the kernels began the be more restictive on checking valid btrfsdisks.I tried to remove the raid and converted to single with several balances after that so that there are no raidchunks left.Label: 'System' uuid: 35fdbfd4-5809-4a30-94c1-5e3ca206ca4d Total devices 1 FS bytes used 14.86GiBdevid6 size 50.00GiB used 17.31GiB path /dev/nvme0n1p1Data, single: total=15.00GiB, used=13.84GiBSystem, single: total=64.00MiB, used=16.00KiBMetadata, single: total=2.25GiB, used=1.02GiBGlobalReserve, single: total=336.00MiB, used=0.00B/dev/nvme0n1p1, ID: 6 Device size:50.00GiB Data,single:15.00GiB Metadata,single: 2.25GiB System,single: 6400MiB Unallocated:32.69GiBOverall:Device size: 50.00GiB Device allocated: 17.31GiBDevice unallocated: 32.69GiBDevice missing: 0.00BUsed: 1486GiBFree (estimated): 33.85GiB(min: 33.85GiB)Data ratio: 1.00Metadata ratio: 1.00Global reserve: 336.00MiB(used: 0.00B)Data,single: Size:15.00GiB, Used:13.84GiB /dev/nvme0n1p1 15.00GiBMetadata,single: Size:2.25GiB, Used:1.02GiB /dev/nvme0n1p1 2.25GiBSystem,single: Size:64.00MiB, Used:1600KiB /dev/nvme0n1p1 64.00MiBUnallocated: /dev/nvme0n1p1 32.69GiBBut again newer kernels refuse to boot with tlling me: "BTRFS error: super_num_devices 2 missmatchwith num_devices 1 found here".So the the two counters are alwasy off by one, dont matter what i try.Question: how do i get thouse two counters in sync again so that my system acts again as expected?!regardsSash -- 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: Fix bool initialization/comparison
Bool initializations should use true and false. Bool tests don't need
comparisons.
Signed-off-by: Thomas Meyer
---
diff -u -p a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6958,7 +6958,7 @@ static int __btrfs_free_extent(struct bt
BUG_ON(!is_data && refs_to_drop != 1);
if (is_data)
- skinny_metadata = 0;
+ skinny_metadata = false;
ret = lookup_extent_backref(trans, info, path, &iref,
bytenr, num_bytes, parent,
@@ -9311,7 +9311,7 @@ out:
* don't have it in the radix (like when we recover after a power fail
* or unmount) so we don't leak memory.
*/
- if (!for_reloc && root_dropped == false)
+ if (!for_reloc && !root_dropped)
btrfs_add_dead_root(root);
if (err && err != -EAGAIN)
btrfs_handle_fs_error(fs_info, err, NULL);
diff -u -p a/fs/btrfs/file.c b/fs/btrfs/file.c
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2046,7 +2046,7 @@ int btrfs_sync_file(struct file *file, l
struct btrfs_trans_handle *trans;
struct btrfs_log_ctx ctx;
int ret = 0, err;
- bool full_sync = 0;
+ bool full_sync = false;
u64 len;
/*
diff -u -p a/fs/btrfs/inode.c b/fs/btrfs/inode.c
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4439,9 +4439,9 @@ int btrfs_truncate_inode_items(struct bt
int err = 0;
u64 ino = btrfs_ino(BTRFS_I(inode));
u64 bytes_deleted = 0;
- bool be_nice = 0;
- bool should_throttle = 0;
- bool should_end = 0;
+ bool be_nice = false;
+ bool should_throttle = false;
+ bool should_end = false;
BUG_ON(new_size > 0 && min_type != BTRFS_EXTENT_DATA_KEY);
@@ -4451,7 +4451,7 @@ int btrfs_truncate_inode_items(struct bt
*/
if (!btrfs_is_free_space_inode(BTRFS_I(inode)) &&
test_bit(BTRFS_ROOT_REF_COWS, &root->state))
- be_nice = 1;
+ be_nice = true;
path = btrfs_alloc_path();
if (!path)
@@ -4657,7 +4657,7 @@ delete:
} else {
break;
}
- should_throttle = 0;
+ should_throttle = false;
if (found_extent &&
(test_bit(BTRFS_ROOT_REF_COWS, &root->state) ||
@@ -4676,11 +4676,11 @@ delete:
if (be_nice) {
if (truncate_space_check(trans, root,
extent_num_bytes)) {
- should_end = 1;
+ should_end = true;
}
if (btrfs_should_throttle_delayed_refs(trans,
fs_info))
- should_throttle = 1;
+ should_throttle = true;
}
}
--
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 v4] btrfs: Remove received_uuid during received snapshot ro->rw switch
07.10.2017 00:27, Hans van Kranenburg пишет: > On 10/06/2017 10:07 PM, Andrei Borzenkov wrote: >> >> What is reason behind allowing change from ro to rw in the first place? >> What is the use case? > > I think this is a case of "well, nobody actually has been thinking of > the use cases ever, we just did something yolo" > > Btrfs does not make a difference between snapshots and clones. Other > systems like netapp and zfs do. Btrfs cloud also do that, and just not > expose the ro/rw flag to the outside. > Current pure user-level implementation of btrfs receive requires possibility to switch from rw to ro. So it is not possible to completely hide it. This is different from both NetApp and ZFS. On NetApp destination volume/qtree are always read-only for client access. ZFS explicitly disallows any access to destination until transfer is complete. It was already mentioned that in btrfs destination may be changed before subvolume is changed to ro without anyone noticing it. Ideally btrfs receive needs exclusive access to subvolume with some sort of automatic cleanup if receive fails for any reason. This will ensure atomic (from end user PoV) transfer. > Personally, I would like btrfs to go into that direction, because it > just makes things more clear. This is a snapshot, you cannot touch it. > If you want to make changes, you have to make a rw clone of the snapshot. > > The nice thing for btrfs is that you can remove the snapshot after you > made the rw clone, which you cannot do on a NetApp filer. :o) > >>> Even if it wouldn't make sense for some reason, it's a nice thought >>> experiment. :) > > There we go :) > -- 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
