On 5/6/2014 1:59 πμ, Konstantinos Skarlatos wrote:
Hi, I get this after doing a few runs of rsync on my btrfs filesystem.
kernel: 3.15.0-rc8
filesystem has 6x2tb disks, data is raid 0, fs was created with skinny
metadata, mount options are noatime, compress-force=zlib. No quota or
defrag or any
Fajar A. Nugraha posted on Thu, 05 Jun 2014 10:22:49 +0700 as excerpted:
> (resending to the list as plain text, the original reply was rejected
> due to HTML format)
>
> On Thu, Jun 5, 2014 at 10:05 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> Igor M posted on Thu, 05 Jun 2014 00:15:31 +0200 a
(resending to the list as plain text, the original reply was rejected
due to HTML format)
On Thu, Jun 5, 2014 at 10:05 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Igor M posted on Thu, 05 Jun 2014 00:15:31 +0200 as excerpted:
>
> > Why btrfs becames EXTREMELY slow after some time (months) of usag
Igor M posted on Thu, 05 Jun 2014 00:15:31 +0200 as excerpted:
> Why btrfs becames EXTREMELY slow after some time (months) of usage ?
> This is now happened second time, first time I though it was hard drive
> fault, but now drive seems ok.
> Filesystem is mounted with compress-force=lzo and is us
Based on Documentation/filesystems/btrfs.txt
Signed-off-by: Gui Hecheng
---
sys-utils/mount.8 | 186 ++
1 file changed, 186 insertions(+)
diff --git a/sys-utils/mount.8 b/sys-utils/mount.8
index efa1ae8..ec8eab3 100644
--- a/sys-utils/mount.8
This depends on the kernel patch:
[PATCH] btrfs:replace EINVAL with EOPNOTSUPP for dev_replace
This catches the EOPNOTSUPP and output msg that says dev_replace raid56
is not currently supported. Note that the msg will only be shown when
run dev_replace not in background.
Signed-off-by: Gu
To return EOPNOTSUPP is more user friendly than to return EINVAL,
and then user-space tool will show that the dev_replace operation
for raid56 is not currently supported rather than showing that
there is an invalid argument.
Signed-off-by: Gui Hecheng
---
fs/btrfs/dev-replace.c | 2 +-
1 file ch
On 06/04/2014 12:24 PM, Arnd Bergmann wrote:
>
> For other timekeeping stuff in the kernel, I agree that using some
> 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds,
> ...) has advantages, that's exactly the point I was making earlier
> against simply extending the internal
i can mistake, but i think what:
btrfstune -x # can improve perfomance because this decrease metadata
Also, in last versions of btrfs progs changed from 4k to 16k, it also
can help (but for this, you must reformat fs)
For clean btrfs fi df /, you can try do:
btrfs bal start -f -sconvert=dup,soft -
On Thu, Jun 5, 2014 at 12:27 AM, Fajar A. Nugraha wrote:
> On Thu, Jun 5, 2014 at 5:15 AM, Igor M wrote:
>> Hello,
>>
>> Why btrfs becames EXTREMELY slow after some time (months) of usage ?
>
>> # btrfs fi show
>> Label: none uuid: b367812a-b91a-4fb2-a839-a3a153312eba
>> Total devices 1
On Thu, 5 Jun 2014 05:27:33 +0700
"Fajar A. Nugraha" wrote:
> On Thu, Jun 5, 2014 at 5:15 AM, Igor M wrote:
> > Hello,
> >
> > Why btrfs becames EXTREMELY slow after some time (months) of usage ?
>
> > # btrfs fi show
> > Label: none uuid: b367812a-b91a-4fb2-a839-a3a153312eba
> > Total
On Thu, Jun 5, 2014 at 5:15 AM, Igor M wrote:
> Hello,
>
> Why btrfs becames EXTREMELY slow after some time (months) of usage ?
> # btrfs fi show
> Label: none uuid: b367812a-b91a-4fb2-a839-a3a153312eba
> Total devices 1 FS bytes used 2.36TiB
> devid1 size 2.73TiB used 2.38Ti
Hello,
Why btrfs becames EXTREMELY slow after some time (months) of usage ?
This is now happened second time, first time I though it was hard
drive fault, but now drive seems ok.
Filesystem is mounted with compress-force=lzo and is used for MySQL
databases, files are mostly big 2G-8G.
Copying from
mount(8) will canonicalize pathnames before passing them to the kernel.
Links to e.g. /dev/sda will be resolved to /dev/sda. Links to /dev/dm-#
will be resolved using the name of the device mapper table to
/dev/mapper/.
Btrfs will use whatever name the user passes to it, regardless of whether
it i
On Jun 4, 2014, at 7:15 AM, Martin wrote:
>
> Consider using noatime as a /default/ being as there are no known
> 'must-use' use cases.
The quote I'm finding on the interwebs is POSIX “requires that operating
systems maintain file system metadata that records when each file was last
accessed
On Wednesday 04 June 2014 13:30:32 Nicolas Pitre wrote:
> On Wed, 4 Jun 2014, Arnd Bergmann wrote:
>
> > On Tuesday 03 June 2014, Dave Chinner wrote:
> > > Just ot be pedantic, inodes don't need 96 bit timestamps - some
> > > filesystems can *support up to* 96 bit timestamps. If the kernel
> > > o
On Wed, 4 Jun 2014, Arnd Bergmann wrote:
> On Tuesday 03 June 2014, Dave Chinner wrote:
> > Just ot be pedantic, inodes don't need 96 bit timestamps - some
> > filesystems can *support up to* 96 bit timestamps. If the kernel
> > only supports 64 bit timestamps and that's all the kernel can
> > rep
On Wed, Jun 04, 2014 at 09:19:26AM +0200, Christian Hesse wrote:
> > It seems to be related to default gcc flags from distribution?
>
> Probably. I did compile with optimization, so adding -O2 may do the trick:
>
> make CFLAGS="${CFLAGS} -O2" all
The warning appears with -O2, so the question is
On Tuesday 03 June 2014, Dave Chinner wrote:
> On Tue, Jun 03, 2014 at 04:22:19PM +0200, Arnd Bergmann wrote:
> > On Monday 02 June 2014 14:57:26 H. Peter Anvin wrote:
> > > On 06/02/2014 12:55 PM, Arnd Bergmann wrote:
> > The possible uses I can see for non-ktime_t types in the kernel are:
> > * i
On Monday 02 June 2014, Joseph S. Myers wrote:
> On Mon, 2 Jun 2014, Arnd Bergmann wrote:
>
> > Ok. Sorry about missing linux-api, I confused it with linux-arch, which
> > may not be as relevant here, except for the one question whether we
> > actually want to have the new ABI on all 32-bit archit
On 4 June 2014 14:30, Russell Coker wrote:
> On Wed, 4 Jun 2014 13:19:16 Stefan Malte Schumacher wrote:
>> I have created multiple filesystems with btrfs, in all cases directly
>> on the devices themself without creating partitions beforehand.
>
> I do that sometimes, it works well. I've done the
On 06/03/2014 11:53 AM, David Sterba wrote:
> On Sat, May 31, 2014 at 11:48:28PM +, Philip Worrall wrote:
>> LZ4 is a lossless data compression algorithm that is focused on
>> compression and decompression speed. LZ4 gives a slightly worse
>> compression ratio compared with LZO (and much worse
On Wed, 4 Jun 2014 13:19:16 Stefan Malte Schumacher wrote:
> I have created multiple filesystems with btrfs, in all cases directly
> on the devices themself without creating partitions beforehand.
I do that sometimes, it works well. I've done the same thing with Ext2/3 in
the past as well, it's
On 04/06/14 10:19, Erkki Seppala wrote:
> Martin writes:
>
>> The *ONLY* application that I know of that uses atime is Mutt and then
>> *only* for mbox files!...
>
> However, users, such as myself :), can be interested in when a certain
> file has been last accessed. With snapshots I can even ge
Signed-off-by: Antonio Ospite
Cc: Chris Mason
Cc: Josef Bacik
Cc: linux-btrfs@vger.kernel.org
---
fs/btrfs/ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 2f6d7b1..b0a206f 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioct
Hello
I have created multiple filesystems with btrfs, in all cases directly
on the devices themself without creating partitions beforehand. Now,
if I open the disks containing the multi-device filesystem in parted
it outputs the partion table as loop and shows one partition with
btrfs which cover
Martin writes:
> The *ONLY* application that I know of that uses atime is Mutt and then
> *only* for mbox files!...
However, users, such as myself :), can be interested in when a certain
file has been last accessed. With snapshots I can even get an idea of
all the times the file has been accesse
Peter Chant posted on Tue, 03 Jun 2014 23:21:55 +0100 as excerpted:
> On 06/03/2014 05:46 AM, Duncan wrote:
>
>> Of course if you were using something like find and executing defrag on
>> each found entry, then yes it would recurse, as find would recurse
>> across filesystems and keep going (unle
Originally this problem was reproduced by the following scripts:
# dd if=/dev/zero of=data bs=1M count=50
# losetup /dev/loop1 data
# i=1
# while [ 1 ]
do
mkfs.btrfs -fK /dev/loop1 >& /dev/null || exit 1
i++
echo "loop $i"
done
Further, a easy way to trigg
On Sun, Jun 01, 2014 at 01:50:28AM +0100, Filipe David Borba Manana wrote:
> If the NO_HOLES feature is enabled holes don't have file extent items in
> the btree that represent them anymore. This made the clone operation
> ignore the gaps that exist between consecutive file extent items and
> there
Qu Wenruo on Wed, 2014/06/04 14:48:
>
> Original Message
> Subject: [PATCH 1/1] btrfs-progs: fix compiler warning
> From: Christian Hesse
> To: linux-btrfs@vger.kernel.org
> Date: 2014年06月03日 19:29
> > gcc 4.9.0 gives a warning: array subscript is above array bounds
> >
> > Che
31 matches
Mail list logo
