Original Message
Subject: Re: Why is the actual disk usage of btrfs considered unknowable?
From: ashf...@whisperpc.com
To: kreij...@inwind.it
Date: 2014å¹´12æ08æ¥ 08:12
Goffredo,
So in case you have a raid1 filesystem on two disks; each disk has
300GB
free; which is
On Sun, Dec 7, 2014 at 1:32 PM, ashf...@whisperpc.com wrote:
I disagree. My experiences with other file-systems, including ZFS, show
that the most common solution is to just deliver to the user the actual
amount of unused disk space. Anything else changes this known value into
a guess or
On 2014-12-05 13:11, Shriramana Sharma wrote:
OK so from https://forums.opensuse.org/showthread.php/440209-ifconfig
I learnt that it's because /sbin, /usr/sbin etc is not on the normal
user's path on openSUSE (they are, on Kubuntu). Adding them to PATH
fixes the situation. (I wasn't even able to
On Sun, Dec 7, 2014 at 4:31 PM, Filipe Manana fdman...@suse.com wrote:
When we abort a transaction we iterate over all the ranges marked as
dirty
in fs_info-freed_extents[0] and fs_info-freed_extents[1], clear them
from those trees, add them back (unpin) to the free space caches and,
if
the fs
It doesn't do anything special, it just calls btrfs_discard_extent(),
so just remove it.
Signed-off-by: Filipe Manana fdman...@suse.com
---
fs/btrfs/ctree.h| 4 ++--
fs/btrfs/extent-tree.c | 10 ++
fs/btrfs/free-space-cache.c | 4 ++--
3 files changed, 6 insertions(+),
On Mon, Dec 8, 2014 at 1:53 PM, Chris Mason c...@fb.com wrote:
On Sun, Dec 7, 2014 at 4:31 PM, Filipe Manana fdman...@suse.com wrote:
When we abort a transaction we iterate over all the ranges marked as dirty
in fs_info-freed_extents[0] and fs_info-freed_extents[1], clear them
from those
On Mon, Dec 8, 2014 at 6:31 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
Personally, I prefer a somewhat hybrid approach where everyone has *sbin in
their path, but file permissions are used to control what non-administrators
can run.
This is exactly the same approach as Ubuntu, since
On 12/08/2014 01:12 AM, ashf...@whisperpc.com wrote:
Goffredo,
So in case you have a raid1 filesystem on two disks; each disk has 300GB
free; which is the free space that you expected: 300GB or 600GB and why ?
You should see 300GB free. That's what you'll see with RAID-1 with a
hardware
Hi,
Am Sonntag, 7. Dezember 2014, 21:32:01 schrieb Robert White:
On 12/07/2014 07:40 AM, Martin Steigerwald wrote:
Well what would be possible I bet would be a kind of system call like
this:
I need to write 5 GB of data in 100 of files to /opt/mynewshinysoftware,
can I do it *and*
On 2014-12-08 09:16, Shriramana Sharma wrote:
On Mon, Dec 8, 2014 at 6:31 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
Personally, I prefer a somewhat hybrid approach where everyone has *sbin in
their path, but file permissions are used to control what non-administrators
can run.
This
On 12/08/2014 03:02 AM, Qu Wenruo wrote:
Original Message
Subject: [PATCH 1/5] Avoid to consider lvm snapshots when scanning devices.
From: Goffredo Baroncelli kreij...@gmail.com
To: linux-btrfs@vger.kernel.org
Date: 2014年12月05日 02:39
LVM snapshots create a problem to the
On 2014-12-08 09:47, Martin Steigerwald wrote:
Hi,
Am Sonntag, 7. Dezember 2014, 21:32:01 schrieb Robert White:
On 12/07/2014 07:40 AM, Martin Steigerwald wrote:
Well what would be possible I bet would be a kind of system call like
this:
I need to write 5 GB of data in 100 of files to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/7/2014 7:32 PM, Konstantin wrote:
I'm guessing you are using metadata format 0.9 or 1.0, which put
the metadata at the end of the drive and the filesystem still
starts in sector zero. 1.2 is now the default and would not have
this problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/4/2014 1:39 PM, Goffredo Baroncelli wrote:
LVM snapshots are a problem for the btrfs devices management. BTRFS
assumes that each device have an unique 'device UUID'. A LVM
snapshot breaks this assumption.
This causes a lot of problems if
Am Montag, 8. Dezember 2014, 09:57:50 schrieb Austin S Hemmelgarn:
On 2014-12-08 09:47, Martin Steigerwald wrote:
Hi,
Am Sonntag, 7. Dezember 2014, 21:32:01 schrieb Robert White:
On 12/07/2014 07:40 AM, Martin Steigerwald wrote:
Well what would be possible I bet would be a kind of
On 12/07/2014 04:32 PM, Konstantin wrote:
I know this and I'm using 0.9 on purpose. I need to boot from these
disks so I can't use 1.2 format as the BIOS wouldn't recognize the
partitions. Having an additional non-RAID disk for booting introduces a
single point of failure which contrary to the
On 12/08/2014 04:30 PM, Phillip Susi wrote:
On 12/4/2014 1:39 PM, Goffredo Baroncelli wrote:
[...]
To check if a device is a LVM snapshot, it is checked the 'udev'
device property 'DM_UDEV_LOW_PRIORITY_FLAG' . If it is set to 1,
the device has to be skipped.
As consequence, btrfs now
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/8/2014 12:36 PM, Goffredo Baroncelli wrote:
I like this approach, but as I wrote before, it seems that
initramfs executes a btrfs dev scan (see my previoue email
'Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their
snapshots'
On Sun, Nov 30, 2014 at 2:29 AM, Guenther Starnberger
linux-bt...@gst.priv.at wrote:
Here's the log output:
dmesg:
[235491.227888] [ cut here ]
[235491.227912] WARNING: CPU: 0 PID: 14837 at fs/btrfs/super.c:259
__btrfs_abort_transaction+0x50/0x110 [btrfs]()
Phillip Susi schrieb am 08.12.2014 um 15:59:
On 12/7/2014 7:32 PM, Konstantin wrote:
I'm guessing you are using metadata format 0.9 or 1.0, which put
the metadata at the end of the drive and the filesystem still
starts in sector zero. 1.2 is now the default and would not have
this
This is my latest attempt at a target for testing power fail and fs consistency.
This is based on the idea Zach Brown had where we could just walk through all
the operations done to an fs in order to verify we're doing the correct thing.
There is a userspace component as well that can be found
Robert White schrieb am 08.12.2014 um 18:20:
On 12/07/2014 04:32 PM, Konstantin wrote:
I know this and I'm using 0.9 on purpose. I need to boot from these
disks so I can't use 1.2 format as the BIOS wouldn't recognize the
partitions. Having an additional non-RAID disk for booting introduces a
On Mon, Dec 08, 2014 at 03:47:23PM +0100, Martin Steigerwald wrote:
Am Sonntag, 7. Dezember 2014, 21:32:01 schrieb Robert White:
On 12/07/2014 07:40 AM, Martin Steigerwald wrote:
Almost full filesystems are their own reward.
So you basically say that BTRFS with compression does not meet
On 12/08/2014 02:38 PM, Konstantin wrote:
For more important systems there are high availability
solutions which alleviate many of the problems you mention of but that's
not the point here when speaking about the major bug in BTRFS which can
make your system crash.
I think you missed the part
Hi Goffredo
On 12/08/2014 03:02 AM, Qu Wenruo wrote:
Original Message
Subject: [PATCH 1/5] Avoid to consider lvm snapshots when scanning devices.
From: Goffredo Baroncelli kreij...@gmail.com
To: linux-btrfs@vger.kernel.org
Date: 2014年12月05日 02:39
LVM snapshots create a
Hi all,
Our specifications are:
- Debian 7.7
- kernel version: 3.17.4
Two weeks ago we started a btrfs balance. Some days later we stopped the
balance. The messages log show some errors (see below).
While balancing we removed some snapshots, this operations failed with a
error messages.
26 matches
Mail list logo
