On 12/07/2014 10:20 PM, ashf...@whisperpc.com wrote:
Martin,
Excellent analysis.
On 12/07/2014 07:40 AM, Martin Steigerwald wrote:
So while the core problem isn't insoluble, in real life it is _not_
_worth_ _solving_.
Your email quoting things is messed up... I wrote that analysis... 8-)
On Sun, Dec 07, 2014 at 08:45:59PM +0530, Shriramana Sharma wrote:
> IIUC:
>
> 1) btrfs fi df already shows the alloc-ed space and the space used out of
> that.
>
> 2) Despite snapshots, CoW and compression, the tree knows how many
> extents of data and metadata there are, and how many bytes on
Martin,
Excellent analysis.
> On 12/07/2014 07:40 AM, Martin Steigerwald wrote:
>
> So while the core problem isn't insoluble, in real life it is _not_
> _worth_ _solving_.
I agree. There is inadequate return on the investment. In addition, the
number of corner cases increases dramatically, ma
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* give me a guarentee I can.
So like a more flexible fallocate approach as fallo
On Sun, Dec 7, 2014 at 11:34 AM, Hugo Mills wrote:
>*Any* value shown here is going to be inaccurate, and whatever way
> round we show it, someone will complain.
Yeah I'd suggest that for regular df command, when multiple device
volumes exist, they're shown with ?? for Avail and Use% columns
On 12/07/2014 07:15 AM, Shriramana Sharma wrote:
IIUC:
1) btrfs fi df already shows the alloc-ed space and the space used out of that.
2) Despite snapshots, CoW and compression, the tree knows how many
extents of data and metadata there are, and how many bytes on disk
these occcupy, no matter w
The RCU-friendly string API used internally by BTRFS is generic enough
for common use. This doesn't add any new functionality but instead just
moves the code and documents the existing API.
Reviewed-by: Josh Triplett
Acked-by: Paul E. McKenney
Signed-off-by: Omar Sandoval
---
fs/btrfs/check-in
The rcu_string API introduced some new sparse errors but also revealed
existing ones. First of all, the name in struct btrfs_device should be
annotated as __rcu to prevent unsafe reads. Additionally, updates should
go through rcu_dereference_protected to make it clear what's going on.
This introduc
This patch series on top of v3.18 introduces the RCU string API and cleans up
the wreckage of sparse warnings which follow from it (shown here from when the
patch was briefly in the btrfs integration tree):
On Thu, Nov 27, 2014 at 06:45:20AM +0800, kbuild test robot wrote:
> tree: git://git.kern
A naked read of the value of an RCU pointer isn't safe. Put the whole
access in an RCU critical section, not just the pointer dereference.
Signed-off-by: Omar Sandoval
---
fs/btrfs/ioctl.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/
Original Message
Subject: Re: Why is the actual disk usage of btrfs considered unknowable?
From:
To:
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 the free space that you expected: 300GB or 600GB an
Original Message
Subject: [PATCH 1/5] Avoid to consider lvm snapshots when scanning devices.
From: Goffredo Baroncelli
To:
Date: 2014年12月05日 02:39
LVM snapshots create a problem to the btrfs devices management.
BTRFS assumes that each device haw an unique 'device UUID'.
A LVM
Original Message
Subject: Re: System/single + Metadata/single as leftover cruft of mkfs?
From: Goffredo Baroncelli
To: Shriramana Sharma , linux-btrfs
Date: 2014年12月05日 02:32
On 12/04/2014 02:53 PM, Shriramana Sharma wrote:
I observe that whenever I create a BtrFS instance
Phillip Susi wrote on 02.12.2014 at 20:19:
> On 12/1/2014 4:45 PM, Konstantin wrote:
> > The bug appears also when using mdadm RAID1 - when one of the
> > drives is detached from the array then the OS discovers it and
> > after a while (not directly, it takes several minutes) it appears
> > under /
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 RAID controller, and with MD RAID. Why would you expect
Anand Jain wrote on 02.12.2014 at 12:54:
>
>
>
> On 02/12/2014 19:14, Goffredo Baroncelli wrote:
>> I further investigate this issue.
>>
>> MegaBrutal, reported the following issue: doing a lvm snapshot of the
>> device of a
>> mounted btrfs fs, the new snapshot device name replaces the name of
>>
On 12/07/2014 09:32 PM, ashf...@whisperpc.com wrote:
>> In conclusion, the disk usage is well known; which is unknown is
>> > the space that is available to the user (who is uninterested to
>> > all the details inside a filesystem). The best that is doable
>> > is an estimation like the above one.
On Sun, Nov 23, 2014 at 07:52:29AM +, Duncan wrote:
> > Right. So, why would you rebalance empty chunks or near empty chunks?
> > Don't you want to rebalance almost full chunks first, and work you way
> > to less and less full as needed?
>
> No, the closer to empty a chunk is, the more effect
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 was mounted with "-o discard", perform a discard on those regions.
Also,
> 3.1) even in the case of a single disk filesystem, data and metadata
> have different profiles: the data chunk doesn't have any redundancy,
> so 64kb of data consume 64kb of disk space. The metadata chunks
> usually are stored as DUP, so 64kb of metadata consume 128kb on disk.
> Moreover you have
> Am Sonntag, 7. Dezember 2014, 10:20:27 schrieb ashf...@whisperpc.com:
>> Martin,
>>
>> > I read that the actual
>> > what is free is unknown. And there are several reasons for that:
>> >
>> > 1) On a compressed filesystem you cannot know, but only estimate the
>> > compression ratio for future da
> On Sun, Dec 07, 2014 at 10:20:27AM -0800, ashf...@whisperpc.com wrote:
> [snip]
>> > 3) From what I gathered it is planned to allow different raid /
>> > redundancy levels for different subvolumes. BTRFS can´t know
>> > beforehand where applications request to save future data, i.e.
>> > in whic
On Sat, Dec 6, 2014 at 7:45 PM, Andrew Wade wrote:
> I've had repeated lockups as well; I can trigger them by attempting to
> copy files off of a damaged DVD.
>
> I saw the btrfs_assert_delayed_root_empty warning as well, but not
> during the lockup; instead I saw it on a boot after a lockup.
>
>
On 12/07/2014 04:33 PM, Martin Steigerwald wrote:
> Hi Shriramana!
>
> Am Sonntag, 7. Dezember 2014, 20:45:59 schrieb Shriramana Sharma:
>>> IIUC:
>>>
>>> 1) btrfs fi df already shows the alloc-ed space and the space
>>> used out of that.
>>>
>>> 2) Despite snapshots, CoW and compression, the t
Am Sonntag, 7. Dezember 2014, 18:34:44 schrieb Hugo Mills:
> On Sun, Dec 07, 2014 at 10:20:27AM -0800, ashf...@whisperpc.com wrote:
> [snip]
>
> > > 3) From what I gathered it is planned to allow different raid /
> > > redundancy levels for different subvolumes. BTRFS can´t know
> > > beforehand
Am Sonntag, 7. Dezember 2014, 10:20:27 schrieb ashf...@whisperpc.com:
> Martin,
>
> > I read that the actual
> > what is free is unknown. And there are several reasons for that:
> >
> > 1) On a compressed filesystem you cannot know, but only estimate the
> > compression ratio for future data.
>
On Sun, Dec 07, 2014 at 10:20:27AM -0800, ashf...@whisperpc.com wrote:
[snip]
> > 3) From what I gathered it is planned to allow different raid /
> > redundancy levels for different subvolumes. BTRFS can´t know
> > beforehand where applications request to save future data, i.e.
> > in which subvol
Martin,
> I read that the actual
> what is free is unknown. And there are several reasons for that:
>
> 1) On a compressed filesystem you cannot know, but only estimate the
> compression ratio for future data.
It is NOT the job of BTRFS, or ANY file-system, to try to prodict the
future. The futu
On Fri, Dec 05, 2014 at 12:28:57PM -0500, moparisthebest wrote:
> Hello all,
>
> I had a 6-device array I added a 4tb device to last night and ran the
> command to remove a previous 4tb device that still worked fine
> overnight. Unfortunately, one of the OTHER devices completely failed
> while th
On Sun, Dec 7, 2014 at 12:50 AM, Sandy McArthur Jr wrote:
> Would the `btrfs check` output below indicate "only small error" and
> that a --repair is likely to succeed?
It did. Thanks Qu and Duncan.
dmesg suggests I have some scrubbing to do:
[220283.369150] BTRFS: bdev /dev/sdh1 errs: wr 0, rd
Am Sonntag, 7. Dezember 2014, 16:33:37 schrieb Martin Steigerwald:
> What might be possible but still has the limitation of the fourth point
> above, would be a query: How much free space do you have *right* know, on
> this directory path, if I write with standard settings.
>
> But the only guara
On Sun, Dec 7, 2014 at 9:03 PM, Martin Steigerwald wrote:
>
> I never read that the actual disk usage is unknown. But I read that the actual
> what is free is unknown. And there are several reasons for that:
That is totally understood. But I guess when your alloc space is
nearing 90% of your disk
Hi Shriramana!
Am Sonntag, 7. Dezember 2014, 20:45:59 schrieb Shriramana Sharma:
> IIUC:
>
> 1) btrfs fi df already shows the alloc-ed space and the space used out of
> that.
>
> 2) Despite snapshots, CoW and compression, the tree knows how many
> extents of data and metadata there are, and how
IIUC:
1) btrfs fi df already shows the alloc-ed space and the space used out of that.
2) Despite snapshots, CoW and compression, the tree knows how many
extents of data and metadata there are, and how many bytes on disk
these occcupy, no matter what is the total (uncompressed,
"unsnapshotted") si
On 2014-12-07 06:26, Chris Murphy wrote:
On Sat, Dec 6, 2014 at 2:17 AM, Tomasz Chmielewski
wrote:
After we run again btrfs device delete missing /home, the newly
created
directory eventually (/home/backup/ma-int/weekly.tmp) is being
detected as
"csum failed ino ...".
If that comes up cl
35 matches
Mail list logo
