On 2016 Sep 20, Peter Becker wrote:
> Data, RAID1: total=417.12GiB, used=131.33GiB
>
> You have 417(total)-131(used) blocks wo are only partial filled.
> You should balance your file-system.
>
> At first you need some free space. You could remove some files / old
> snapshots etc. or you add a
.
Some btrfs utils output first:
# btrfs fi show /var/lib/lxd
Label: 'btrfs' uuid: f5f30428-ec5b-4497-82de-6e20065e6f61
Total devices 2 FS bytes used 182.93GiB
devid1 size 423.13GiB used 423.13GiB path /dev/sda3
devid2 size 423.13GiB used 423.13GiB path /dev/sdb3
with that kernel. As in, just
change kernels, don't try to fix it with balance first.
Looks like 4.8 helped (running 4.8rc8 now).
With 4.7, after balance, the "used" value continued to grow, to around
300 GB, although used space shown by "df" was more or less constant at
130-140 GB:
>
>> Because of a possible bug you should disable all snapshot scripts
>> (like cron-jobs) during the balance.
>>
>> If this solve the "No space left" issues you must remove old snapshots.
>>
>> 2016-09-20 8:58 GMT+02:00 Hugo Mills <h...@ca
On Tue, Sep 20, 2016 at 03:47:14PM +0900, Tomasz Chmielewski wrote:
> How to understand the following "btrfs fi show" output?
This gives a write-up (and worked example) of an answer to your question:
https://btrfs.wiki.kernel.org/index.php/FAQ#Understanding_free_space.2C_using_the_o
Zygo Blaxell posted on Thu, 15 Oct 2015 00:39:27 -0400 as excerpted:
> As others have pointed out, the raid0 allocator has a 2-disk-minimum
> constraint, so any difference in size between the largest and
> second-largest disk is unusable. In your case that's 73% of the raw
> space.
>
> If the
rt -dconvert=raid0
> > /` and as soon as I run `btrfs fi show /` I lost my ssh connection to
> > the machine. The machine is still on, but it doesn’t even respond to
> > ping[. ...]
> >
> > (I have a 250gb internal hard drive, a 120gb usb 2.0 one and a 2TB usb
> > 2.0 o
me
>> > btrfs filesystem. Several hours ago I run `btrfs balance start
>> > -dconvert=raid0 /` and as soon as I run `btrfs fi show /` I lost my
>> > ssh connection to the machine. The machine is still on, but it
>> > doesn’t even respond to ping[. ...]
>>
On Tue, Oct 13, 2015 at 11:21:49PM +0200, Carmine Paolino wrote:
> I have an home server with 3 hard drives that I added to the same btrfs
> filesystem. Several hours ago I run `btrfs balance start -dconvert=raid0
> /` and as soon as I run `btrfs fi show /` I lost my ssh c
start -dconvert=raid0
/` and as soon as I run `btrfs fi show /` I lost my ssh connection to
the machine. The machine is still on, but it doesn’t even respond to
ping[. ...]
(I have a 250gb internal hard drive, a 120gb usb 2.0 one and a 2TB usb
2.0 one so the transfer speeds are pretty low)
I won't
Carmine Paolino posted on Tue, 13 Oct 2015 23:21:49 +0200 as excerpted:
> I have an home server with 3 hard drives that I added to the same btrfs
> filesystem. Several hours ago I run `btrfs balance start -dconvert=raid0
> /` and as soon as I run `btrfs fi show /` I lost my ssh c
Hi all,
I have an home server with 3 hard drives that I added to the same btrfs
filesystem. Several hours ago I run `btrfs balance start -dconvert=raid0 /` and
as soon as I run `btrfs fi show /` I lost my ssh connection to the machine. The
machine is still on, but it doesn’t even respond
Since the 4.0 update, fi show only gives me a version number. Anyone else?
btrfs-progs-4.0-1.fc22.x86_64
kernel-4.0.1-300.fc22.x86_64
--
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
Commit 8be2fff (btrfs-progs: apply realpath for btrfs fi
show when mount point is given) changed the behavior of
btrfs fi show to return an error if the call to realpath()
failed. This broke the ability to specify a filesystem by
uuid or label.
So let's not consider a failed call to realpath
On Tue, 2014-12-23 at 11:34 -0800, Justin Maggard wrote:
Commit 8be2fff (btrfs-progs: apply realpath for btrfs fi
show when mount point is given) changed the behavior of
btrfs fi show to return an error if the call to realpath()
failed. This broke the ability to specify a filesystem by
uuid
On 12/04/2014 05:50 AM, Shriramana Sharma wrote:
[samjnaa:~] mount | grep btrfs
/dev/sdb1 on /run/media/samjnaa/BRIHATII type btrfs
(rw,nosuid,nodev,relatime,space_cache,uhelper=udisks2)
[samjnaa:~] sudo btrfs fi show /run/media/samjnaa/BRIHATII/
Btrfs v3.17+20141103
[samjnaa:~]
But the manpage
On Thu, 2014-12-04 at 19:20 +0530, Shriramana Sharma wrote:
Using SuSE Tumbleweed. Observe:
[samjnaa:~] sudo btrfs fi show
root's password:
Label: 'BRIHATII' uuid: 57836428-576e-466b-8a28-7961712867ab
Total devices 1 FS bytes used 460.19GiB
devid1 size 931.51GiB used
For now,
# btrfs fi show /mnt/btrfs
gives info correctly, while
# btrfs fi show /mnt/btrfs/
gives nothing.
This implies that the @realpath() function should be applied to
unify the behavior.
Made a more clear comment right above the call as well.
Signed-off-by: Gui Hecheng
The @fi_args-num_devices in @get_fs_info() does not include seed devices.
We could just correct it by searching the chunk tree and count how
many dev_items there are in total which includes seed devices.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
changelog
v1-v2: adopt more
When using lvm volumes to check fstests: btrfs/006, it fails like:
Label: 'TestLabel.006' uuid: UUID
Total devices EXACTNUM FS bytes used SIZE
devid DEVID size SIZE used SIZE path SCRATCH_DEV
+ devid DEVID size SIZE used SIZE path /dev/dm-4
+ devid DEVID size SIZE
On Sat, 2014-11-08 at 19:47 +, Mike Fleetwood wrote:
On 7 November 2014 18:16, David Sterba dste...@suse.cz wrote:
On Fri, Nov 07, 2014 at 10:07:43AM +0800, Gui Hecheng wrote:
The @fi_args-num_devices in @get_fs_info() does not include seed devices.
We could just correct it by searching
On 7 November 2014 18:16, David Sterba dste...@suse.cz wrote:
On Fri, Nov 07, 2014 at 10:07:43AM +0800, Gui Hecheng wrote:
The @fi_args-num_devices in @get_fs_info() does not include seed devices.
We could just correct it by searching the chunk tree and count how
many dev_items there are in
On Fri, Nov 07, 2014 at 10:07:43AM +0800, Gui Hecheng wrote:
The @fi_args-num_devices in @get_fs_info() does not include seed devices.
We could just correct it by searching the chunk tree and count how
many dev_items there are in total which includes seed devices.
Signed-off-by: Gui Hecheng
really nice fix. Thanks Gui.
Anand
On 08/11/2014 02:16, David Sterba wrote:
On Fri, Nov 07, 2014 at 10:07:43AM +0800, Gui Hecheng wrote:
The @fi_args-num_devices in @get_fs_info() does not include seed devices.
We could just correct it by searching the chunk tree and count how
many dev_items
The @fi_args-num_devices in @get_fs_info() does not include seed devices.
We could just correct it by searching the chunk tree and count how
many dev_items there are in total which includes seed devices.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
*Note*
This is just a temporary
The following BUG_ON:
BUG_ON(ndevs = fi_args-num_devices)
is not needed, because it always fails with seed devices present.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
utils.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/utils.c b/utils.c
index f10c178..9bcc1a0 100644
Summary: After successfully completed btrfs replace start, btrfs fi show lists
the old devid size not the new devid size.
kernel-3.17.2-300.fc21.x86_64
btrfs-progs-3.17-1.fc21.x86_64
##Before devid2 is missing (normal mount of 2x HDDs, raw block devices are
formatted, no partitioning)
#btrfs
Filed a bug. The btrfs fi show, and (conventional) df command are the same with
kernel-3.18.0-0.rc3.git0.1.fc22.x86_64
https://bugzilla.kernel.org/show_bug.cgi?id=87851
I'm going to guess this is a btrfs-progs bug not resizing the file system to
max; I'm pretty sure this was working at one time
On Nov 5, 2014, at 8:28 PM, Chris Murphy li...@colorremedies.com wrote:
Filed a bug. The btrfs fi show, and (conventional) df command are the same
with kernel-3.18.0-0.rc3.git0.1.fc22.x86_64
https://bugzilla.kernel.org/show_bug.cgi?id=87851
I'm going to guess this is a btrfs-progs bug
On 11/06/2014 10:57 AM, Chris Murphy wrote:
Summary: After successfully completed btrfs replace start, btrfs fi show lists
the old devid size not the new devid size.
kernel-3.17.2-300.fc21.x86_64
btrfs-progs-3.17-1.fc21.x86_64
##Before devid2 is missing (normal mount of 2x HDDs, raw block
This is with my small 256 MiB btrfs mixed-bg dup-mode /boot, or actually,
with its backup (same size partition, different device). Kernel 3.17.0,
btrfs-progs 3.16.1 (both actually from git), gentoo.
It was time to renew my backups so I did a mkfs.btrfs on the backup to
start fresh:
Duncan posted on Tue, 07 Oct 2014 13:41:49 + as excerpted:
FWIW, if I try to cp it instead of using mc, 14208 KiB copies before I
get the enospc.
Interesting workaround I just found:
1) cp the file and let the cp abort.
2) delete the partial copy
3) mc-copy the file.
4) watch the full
to reproduce:
# mkfs.btrfs -f /dev/sda1
# btrfstune -S 1 /dev/sda1
# mount /dev/sda1 /mnt
# btrfs dev add /dev/sda2 /mnt
# umount /mnt == (umounted)
# btrfs fi show /dev/sda2
result:
Label: none uuid: XX
Total
/mnt == (umounted)
# btrfs fi show /dev/sda2
result:
Label: none uuid: XX
Total devices 2 FS bytes used 368.00KiB
devid2 size 9.31GiB used 1.25GiB path /dev/sda2
*** Some devices missing
Btrfs v3.16-67-g69f54ea
# btrfstune -S 1 /dev/sda1
# mount /dev/sda1 /mnt
# btrfs dev add /dev/sda2 /mnt
# umount /mnt == (umounted)
# btrfs fi show /dev/sda2
result:
Label: none uuid: XX
Total devices 2 FS bytes used 368.00KiB
devid2
On Fri, 2014-09-12 at 14:56 +0900, Satoru Takeuchi wrote:
Hi Gui,
(2014/09/12 10:15), Gui Hecheng wrote:
For btrfs fi show, -d|--all-devices -m|--mounted will
overwrite each other, so if specified both, let the user
know that he should not use them at the same time.
Signed-off
For btrfs fi show, -d|--all-devices -m|--mounted will
overwrite each other, so if specified both, let the user
know that he should not use them at the same time.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
changelog:
v1-v2: add option conflict descriptions to manpage
Hi Gui,
(2014/09/12 10:15), Gui Hecheng wrote:
For btrfs fi show, -d|--all-devices -m|--mounted will
overwrite each other, so if specified both, let the user
know that he should not use them at the same time.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
changelog:
v1
For btrfs fi show, -d|--all-devices -m|--mounted will
overwrite each other, so if specified both, let the user
know that he should not use them at the same time.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
cmds-filesystem.c | 11 +--
1 file changed, 9 insertions(+), 2
device add /dev/sdc3 /mnt
Performing full device TRIM (75.90GiB) ...
# btrfs fi show
Label: 'rawhide' uuid: d372e5d1-386f-460c-b036-611469e0155e
Total devices 1 FS bytes used 7.55GiB
devid1 size 79.31GiB used 11.04GiB path /dev/sda3
btrfs: utils.c:1769: get_fs_info: Assertion `!(ndevs
Chris,
For the seed replace issues. you have to try this patch set.
Thanks.
https://patchwork.kernel.org/patch/4716371/
Next, for the failing 'btrfs fi show' issue the following diff
is the latest. The last attempt was ..
[PATCH] btrfs: ioctl BTRFS_IOC_FS_INFO and BTRFS_IOC_DEV_INFO
miss
/mnt
mount: /dev/sdb2 is write-protected, mounting read-only
# btrfs device add /dev/sdc3 /mnt
Performing full device TRIM (75.90GiB) ...
# btrfs fi show
Label: 'rawhide' uuid: d372e5d1-386f-460c-b036-611469e0155e
Total devices 1 FS bytes used 7.55GiB
devid1 size 79.31GiB used
is write-protected, mounting read-only
# btrfs device add /dev/sdc3 /mnt
Performing full device TRIM (75.90GiB) ...
# btrfs fi show
Label: 'rawhide' uuid: d372e5d1-386f-460c-b036-611469e0155e
Total devices 1 FS bytes used 7.55GiB
devid1 size 79.31GiB used 11.04GiB path /dev/sda3
btrfs
= unformatted partition
# btrfstune -S1 /dev/sdb2
# mount /dev/sdb2 /mnt
mount: /dev/sdb2 is write-protected, mounting read-only
# btrfs device add /dev/sdc3 /mnt
Performing full device TRIM (75.90GiB) ...
# btrfs fi show
Label: 'rawhide' uuid: d372e5d1-386f-460c-b036-611469e0155e
Total
(75.90GiB) ...
# btrfs fi show
Label: 'rawhide' uuid: d372e5d1-386f-460c-b036-611469e0155e
Total devices 1 FS bytes used 7.55GiB
devid1 size 79.31GiB used 11.04GiB path /dev/sda3
btrfs: utils.c:1769: get_fs_info: Assertion `!(ndevs = fi_args-num_devices)'
failed.
Nothing listed
, mounting read-only
# btrfs device add /dev/sdc3 /mnt
Performing full device TRIM (75.90GiB) ...
# btrfs fi show
Label: 'rawhide' uuid: d372e5d1-386f-460c-b036-611469e0155e
Total devices 1 FS bytes used 7.55GiB
devid1 size 79.31GiB used 11.04GiB path /dev/sda3
btrfs: utils.c
On Tue, May 06, 2014 at 08:10:00PM +, Duncan wrote:
Marc MERLIN posted on Sun, 04 May 2014 22:50:29 -0700 as excerpted:
In the second FS:
Label: btrfs_pool1 uuid: [...]
Total devices 1 FS bytes used 442.17GiB
devid1 size 865.01GiB used 751.04GiB path [...]
The
On 2014/05/07 09:59 AM, Marc MERLIN wrote:
[snip]
Did I get this right?
I'm not sure I did, since it seems the bigger the -dusage number, the
more work balance has to do.
If I asked -dsuage=85, it would do all chunks that are more than 15%
full?
-dusage=85 balances all chunks that up to 85%
On Wed, 7 May 2014 04:30:30 -0700
Marc MERLIN m...@merlins.org wrote:
-dusage=85 balances all chunks that up to 85% full. The higher the
number, the more work that needs to be done.
Aah, right. I see why it's more work. =20 only makes is process the
few chunks that are up to 20% full
Marc MERLIN posted on Sun, 04 May 2014 22:50:29 -0700 as excerpted:
In the second FS:
Label: btrfs_pool1 uuid: [...]
Total devices 1 FS bytes used 442.17GiB
devid1 size 865.01GiB used 751.04GiB path [...]
The difference is huge between 'Total used' and 'devid used'.
Is
On 05/05/14 07:50, Marc MERLIN wrote:
On Mon, May 05, 2014 at 06:11:28AM +0200, Brendan Hide wrote:
The per-device used amount refers to the amount of space that has
been allocated to chunks. That first one probably needs a balance.
Btrfs doesn't behave very well when available diskspace is so
More slides, more questions, sorry :)
(thanks for the other answers, I'm still going through them)
If I have:
gandalfthegreat:~# btrfs fi show
Label: 'btrfs_pool1' uuid: 873d526c-e911-4234-af1b-239889cd143d
Total devices 1 FS bytes used 214.44GB
devid1 size 231.02GB used
On 2014/05/05 02:54 AM, Marc MERLIN wrote:
More slides, more questions, sorry :)
(thanks for the other answers, I'm still going through them)
If I have:
gandalfthegreat:~# btrfs fi show
Label: 'btrfs_pool1' uuid: 873d526c-e911-4234-af1b-239889cd143d
Total devices 1 FS bytes used
On Wed, Feb 12, 2014 at 10:18:26AM +0800, Qu Wenruo wrote:
Please ignore this patchset since adding a new option to
find_mount_root is not the best method to solve the problem.
I'll merge the first patch, it's moving a utility finction to a file
where it IMO belongs.
--
To unsubscribe from this
Please ignore this patchset since adding a new option to find_mount_root
is not the best method to
solve the problem.
I'll send a better version patch to fix it.
Thanks
Qu
On mon, 10 Feb 2014 15:28:27 +0800, Qu Wenruo wrote:
Before this patchset, 'btrfs fi show' can work with '/mnt/point
On fri, 07 Feb 2014 17:26:11 +0800, Anand Jain wrote:
Whats needed is more comprehensive btrfs fi show
which shows the flags (including missing) per disk.
Yes indeed.
And also show the FS/Raid status. Which I am working on.
sorry -p feature would be covered by default in the
coming
Before this patchset, 'btrfs fi show' can work with '/mnt/point' but not
'/mnt/point/',
which is very annoying since tab completion will add '/' to a directory.
This patchset just reuse the find_mount_root function with some small
modification to
ignore the last '/' only when needed.
Qu Wenruo
Whats needed is more comprehensive btrfs fi show
which shows the flags (including missing) per disk.
And also show the FS/Raid status. Which I am working on.
sorry -p feature would be covered by default in the
coming revamp of btrfs fi show.
Thanks, Anand
On 02/07/2014 02:46 PM, Qu
Since a mounted btrfs filesystem contains all the devices info even a
device is removed after mount(like btrfs/003 in xfstests),
we can use the info to print the known missing device if possible.
So -p/--print-missing options are added to print possible missing
devices.
Signed-off-by: Qu Wenruo
2001
From: Chris Mason chris.ma...@fusionio.com
Date: Mon, 18 Nov 2013 14:18:08 -0500
Subject: [PATCH] btrfs filesystem show: skip duplicate fsids
If a given filesystem is mounted more than once, btrfs fi show will
print dups. This adds a quick and dirty hash table of fsids it
has already printed
v2] btrfs: add framework to read fs info from btrfs-control
Thanks, Anand
On 11/16/2013 10:58 PM, Gene Czarcinski wrote:
I am on Fedora 20-Beta and we just updated to btrfs-progs
0.20.rc1-20131114git9f0c53f
Previously, when you did a btrfs fi show, you got a list with one output
for each btrfs
I am on Fedora 20-Beta and we just updated to btrfs-progs
0.20.rc1-20131114git9f0c53f
Previously, when you did a btrfs fi show, you got a list with one output
for each btrfs storage volume whether it was a single device or
multi-device volume.
Now, I get multiple outputs for each storage
On Nov 16, 2013, at 7:58 AM, Gene Czarcinski g...@czarc.net wrote:
I am on Fedora 20-Beta and we just updated to btrfs-progs
0.20.rc1-20131114git9f0c53f
Previously, when you did a btrfs fi show, you got a list with one output for
each btrfs storage volume whether it was a single device
Chris Murphy posted on Sat, 16 Nov 2013 09:04:31 -0700 as excerpted:
On Nov 16, 2013, at 7:58 AM, Gene Czarcinski g...@czarc.net wrote:
I am on Fedora 20-Beta and we just updated to btrfs-progs
0.20.rc1-20131114git9f0c53f
Previously, when you did a btrfs fi show, you got a list with one
On Nov 16, 2013, at 1:33 PM, Duncan 1i5t5.dun...@cox.net wrote:
Meanwhile, in plain English based on my observation here, the new
behavior works like this:
1) If you run a generic btrfs filesystem show (without options or path),
you *WILL* likely get the same base filesystem listed
Chris Murphy posted on Sat, 16 Nov 2013 14:50:00 -0700 as excerpted:
On Nov 16, 2013, at 1:33 PM, Duncan 1i5t5.dun...@cox.net wrote:
1) If you run a generic btrfs filesystem show (without options or
path), you *WILL* likely get the same base filesystem listed multiple
times, as the default
This fixed it.
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/27129
% sudo btrfs fi show /dev/sda3
failed to open /dev/sr0: No medium found
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
Is the error relating to /dev/sr0 relevant to a call to /usr/bin/brtfs? Why
does it show the superfluous output?
% sudo btrfs fi show /dev/sda3
failed to open /dev/sr0: No medium found
Label: 'arch64' uuid: ab6f9133-a2ce-4c92-97ab-35cdc3c2d2a9
Total devices 1 FS bytes used 2.46GB
devid 1
On Aug 10, 2013, at 3:59 AM, Mike Audia mike...@gmx.com wrote:
Is the error relating to /dev/sr0 relevant to a call to /usr/bin/brtfs? Why
does it show the superfluous output?
% sudo btrfs fi show /dev/sda3
failed to open /dev/sr0: No medium found
I get this on Virtual Box VMs, also
=889888#c15
btrfs-progs-0.20.rc1.20121017git92d9eec-1.fc18.x86_64
e2fs-progs-1.42.5-1.fc18.x86_64
kernel 3.7.1-2
Brand new 80GB virtual disk, so it's completely zero'd.
1. fdisk to create one partition, all defaults.
2. Format that sda1 with mkfs.btrfs -L first.
3. btrfs fi show displays
On 01/06/2013 05:26 PM, Goffredo Baroncelli wrote:
Hi Chris
[...]
I will start to update the wiki; then I will give a look to wipefs to
improve it.
Hello I updated the wiki page:
https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#What_if_I_don.27t_have_wipefs_at_hand.3F
-
What if
.x86_64
e2fs-progs-1.42.5-1.fc18.x86_64
kernel 3.7.1-2
Brand new 80GB virtual disk, so it's completely zero'd.
1. fdisk to create one partition, all defaults.
2. Format that sda1 with mkfs.btrfs -L first.
3. btrfs fi show displays first labeled volume.
4. wipefs -a /dev/sda1 and it finds btrfs
On Sunday 29 of April 2012 04:15:24 Duncan wrote:
Still, a zero-superblock option would be useful for the btrfs tool.
I'll see what I can do about this.
Yes, indeed. Particularly since various bits of btrfs functionality
depend on scanning for filesystems (presumably their superblocks),
On Sunday 29 of April 2012 08:13:48 Martin Steigerwald wrote:
Am Donnerstag, 26. April 2012 schrieb Bart Noordervliet:
On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer troh...@ennit.de wrote:
As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe
fi show... I have no clue
what that is about. Did you maybe make a mistake to create a btrfs
filesystem on the whole disk at first?
That is possible. But afterwards I certainly repartioned the device
and created a btrfs filesystem on /dev/sda1. Maybe this info is only
Am Donnerstag, 26. April 2012 schrieb Bart Noordervliet:
On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer troh...@ennit.de wrote:
As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe make a mistake to create a btrfs
filesystem on the whole disk
On Sat, Apr 28, 2012 at 06:42:52PM +0200, Hubert Kario wrote:
On Thursday 26 of April 2012 20:54:47 Duncan wrote:
Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:
Hallo, Bart,
Well I think there is a btrfs superblock still present from the
full-disk filesystem.
On Thursday 26 of April 2012 20:54:47 Duncan wrote:
Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:
Hallo, Bart,
Well I think there is a btrfs superblock still present from the
full-disk filesystem. Due to the offset of the first partition from the
start of the
Hubert Kario posted on Sat, 28 Apr 2012 18:42:52 +0200 as excerpted:
On Thursday 26 of April 2012 20:54:47 Duncan wrote:
Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:
Hallo, Bart,
Well I think there is a btrfs superblock still present from the
full-disk
Hi Thomas,
there's a known regression in 3.3.0 that causes btrfs to report
out-of-space too early. If you upgrade to 3.3.3 or the latest 3.4 rc
the problem should be gone.
As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe make a mistake
Hello Bart,
there's a known regression in 3.3.0 that causes btrfs to report
out-of-space too early. If you upgrade to 3.3.3 or the latest 3.4 rc
the problem should be gone.
thanks for the information. I will update my kernel.
As for the two filesystems shown in btrfs fi show... I have
On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer troh...@ennit.de wrote:
As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe make a mistake to create a btrfs
filesystem on the whole disk at first?
That is possible. But afterwards I certainly
Well I think there is a btrfs superblock still present from the
full-disk filesystem. Due to the offset of the first partition from
the start of the disk, this superblock was not overwritten when you
created the filesystem inside the partition. But they very much
overlap and the full-disk
Hallo, Bart,
Du meintest am 26.04.12:
As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe make a mistake to create a btrfs
filesystem on the whole disk at first?
That is possible. But afterwards I certainly repartioned the device
On Thu, Apr 26, 2012 at 01:11:00PM +0200, Helmut Hullen wrote:
I now use to delete about the first 10 MByte of the target disk via dd
if=/dev/zero
FYI, the minimal amount of data you need to rewrite is 4k:
dd if=/dev/zero of=/dev/ice bs=1k count=4 seek=64
david
--
To unsubscribe from this
Hallo, David,
Du meintest am 26.04.12:
I now use to delete about the first 10 MByte of the target disk via
dd if=/dev/zero
FYI, the minimal amount of data you need to rewrite is 4k:
dd if=/dev/zero of=/dev/ice bs=1k count=4 seek=64
Thank you - I'll try to remember the next time I need
Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:
Hallo, Bart,
Du meintest am 26.04.12:
As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe make a mistake to create a btrfs
filesystem on the whole disk at first
Hello,
I am using btrfs as my root file system on partition sda1. Now I am getting
errors
because of a full device, although df shows a use of only 64%. I read the FAQ
and
understand that this number may not be accurate. But according to the FAQ
btrfs fi show should show a full device.
I am
88 matches
Mail list logo
