I'm trying to figure out an algorithm from taking an arbitrary mounted
btrfs directory and break it down into:
where, keep in mind, may not actually be part of the mount.
/proc/self/mountinfo seems to have some of that information, however, it
does not appear to distinguish between non-default
I just found out that all the device handling in btrfs is based on
pathnames, but shorter pathnames (1024) that PATH_MAX (4096).
This is confusing, and concerning for multiple reasons:
1. pathnames are namespace-specific; what is a pathname in one namespace
might not be in another.
2. different t
Goffredo Baroncelli posted on Mon, 18 Jun 2012 18:47:21 +0200 as
excerpted:
>>> How big was the original ext4 filesystem ?
>>
>> 370 files with ~1GB, and 1 small.
>
> I am a bit confused: 370 files of about ~1GB is about a total of
> 300-400GB; instead you reported
>
root@tv:~# btrfs f
I noticed that btrfs fi defrag -c can't be used to compress files
unless they are fragmented. This patch corrects the problem, by informing
should_defrag_range if compression is enabled, and skipping tests for extent
and adjacent extents if it is.
Andrew Mahone (1):
btrfs: ignore unfragmented fi
Inform should_defrag_range if BTRFS_DEFRAG_RANGE_COMPRESS is set. If so, skip
checks for adjacent extents and extent size when deciding whether to defrag,
as these can prevent an uncompressed and unfragmented file from being
compressed as requested.
Signed-off-by: Andrew Mahone
---
fs/btrfs/ioct
On 06/18/2012 08:40 AM, rupert THURNER wrote:
> On Mon, Jun 18, 2012 at 7:53 AM, Goffredo Baroncelli
> wrote:
>> On 06/17/2012 09:54 PM, rupert THURNER wrote:
>>> displays the additional free space. that it displays 30% of metadata
>>> seems strange to me, or it counts the still existing ext4 sna
Hi,
while doing work, my luks encrypted btrfs home got a nice stacktrace
i run a Debian testing and a kernel 3.4 vanilla
% uname -a
Linux Klappe2 3.4.0 #2 SMP Thu Jun 14 03:02:37 CEST 2012 x86_64 GNU/Linux
the box is a dell xps m 1330 with about 4gb ram
% btrfs fi show
Label: 'home' uuid: 9
When fixing up the locking in the delayed ref destruction work I accidently
broke the locking myself ;(. Add back a spin_lock that should be there and
we are now all set. Thanks,
Btrfs: add a missing spin_lock
When fixing up the locking in the delayed ref destruction work I accidently
broke the
On Mon, Jun 18, 2012 at 04:12:39PM +0300, Dan Carpenter wrote:
> Hello Josef Bacik,
>
> The patch b939d1ab76b4: "Btrfs: fix locking in
> btrfs_destroy_delayed_refs" from May 31, 2012, leads to the following
> warning: Btrfs: fix locking in btrfs_destroy_delayed_refs
>
> fs/btrfs/disk-io.c
> 341
Hello Josef Bacik,
The patch b939d1ab76b4: "Btrfs: fix locking in
btrfs_destroy_delayed_refs" from May 31, 2012, leads to the following
warning: Btrfs: fix locking in btrfs_destroy_delayed_refs
fs/btrfs/disk-io.c
3412 while ((node = rb_first(&delayed_refs->root)) != NULL) {
3413
First: You are absolutely correct, BTRFS is still marked as unstable
and shouldn't be used on data that you will have problems if you lose.
In general, BTRFS is stable on stable workloads(IE no weird hardware
failure, power failure, and the like), but there have been instances
of corruption/data lo
On Fri, Jun 15, 2012 at 05:27:49PM +0300, Andrei Popa wrote:
> On Fri, 2012-06-15 at 12:50 +0200, David Sterba wrote:
> > mount -o compress,nocompress /dev /mnt
> >
> > Is it on or off? Yeah we can document that nocompress has higher
> > priority. But then I can't turn a nocompress option back t
On Fri, Jun 15, 2012 at 06:56:35PM +0200, Goffredo Baroncelli wrote:
> On 06/15/2012 12:50 PM, David Sterba wrote:
> > I prefer this over adding an extra option to disable. This
> > way there's no confusion if the compression is on or off.
> >
> > mount -o compress,nocompress /dev /mnt
>
> The
On Sat, Jun 16, 2012 at 03:37:12PM +0300, Andrei Popa wrote:
> Adds BTRFS_INODE_NODATASUM to inode flags when setting NOCOW for a file
> (chattr +C file).
> In btrfs, NOCOW implies NODATASUM and without setting NODATASUM, btrfs
> doesn't honour correctly the NOCOW attribute.
>
> Signed-off-by: A
I am looking for the opinions on how stable btrfs is when used with a big
server with lots of discs, but no fancy file system usage.
I have read the warnings about btrfs being experimental, and that I should have
tested backups elsewhere.
I am working on a project to set-up a backup server that
15 matches
Mail list logo
