On Thu, 2014-06-05 at 10:03 +0200, Karel Zak wrote:
> On Thu, Jun 05, 2014 at 10:05:19AM +0800, Gui Hecheng wrote:
> > Based on Documentation/filesystems/btrfs.txt
> >
> > Signed-off-by: Gui Hecheng
> > ---
> > sys-utils/mount.8 | 186
> > ++
>
Several reports about leaf corruption has been floating on the list, one of them
points to __btrfs_drop_extents(), and we find that the leaf becomes corrupted
after __btrfs_drop_extents(), it's really a rare case but it does exist.
The problem turns out to be btrfs_next_leaf() called in __btrfs_dr
Robert White posted on Thu, 05 Jun 2014 20:31:21 -0700 as excerpted:
> Is there a way to store the default mount options in the file system a
> la ext4 and tune2fs?
Short answer, no, for most options at least. It has been discussed and
will probably appear in the future, most likely in the form
Is there a way to store the default mount options in the file system a
la ext4 and tune2fs?
In particular my initrd mounts the file system and then the system
remounts it using fstab, but this tends to lead to rebuilds of the inode
cache. The initrd doesn't have the inode_cache option but the
(looks like there was some sendmail problem I don't see this in the btrfs list,
sending again. sorry for multiple copies if any).
device_list_add() is called when user runs btrfs dev scan, which would add
any btrfs device into the btrfs_fs_devices list.
Now think of a mounted btrfs. And a new dev
Regression test for btrfs ioctl clone operation + fsync + log
recovery. The issue was that doing an fsync after cloning into
a file didn't gave any persistence guarantees as it should.
What happened was that the in memory metadata (extent maps)
weren't updated, which made the fsync code not able to
When cloning into a file, we were correctly replacing the extent
items in the target range and removing the extent maps. However
we weren't replacing the extent maps with new ones that point to
the new extents - as a consequence, an incremental fsync (when the
inode doesn't have the full sync flag)
Original Message
Subject: Re: latest btrfs-progs and asciidoc dependency
From: Fajar A. Nugraha
To: Tomasz Chmielewski
Date: 2014年06月05日 22:51
On Thu, Jun 5, 2014 at 9:41 PM, Marc MERLIN wrote:
On Thu, Jun 05, 2014 at 12:52:04PM +0100, Tomasz Chmielewski wrote:
And it look
Attention Dear,
We the management and staff of Multi-National Oil Company have your
email address as a winner in our end of the year email balloting promotion
and have deposited automated teller machine (ATM) visa card of €1.4M
in the custody of Security Company which we kept for you, due to we
di
Martin K. Petersen posted on Thu, 05 Jun 2014 19:58:26 -0400 as excerpted:
>> "Duncan" == Duncan <1i5t5.dun...@cox.net> writes:
>
> Duncan> OTOH, certain high-performance hardware goes beyond the current
> Duncan> standard and does a queued trim, without forcing a flush of the
> Duncan> queu
On Jun 5, 2014, at 5:58 PM, "Martin K. Petersen"
wrote:
>
> Queued trim has started to appear in consumer SSDs. However, since we're
> the only OS that supports it the feature has come off to a bumpy start.
> We tried to enable it on a drive model that passed testing here but we
> had to revert
> "Duncan" == Duncan <1i5t5.dun...@cox.net> writes:
Duncan> OTOH, certain high-performance hardware goes beyond the current
Duncan> standard and does a queued trim, without forcing a flush of the
Duncan> queue in the process. But this hardware tends to be rather rare
Duncan> and expensive,
Marc MERLIN posted on Thu, 05 Jun 2014 12:05:26 -0700 as excerpted:
> On Thu, Jun 05, 2014 at 12:13:37PM -0600, Chris Murphy wrote:
>> I'd say, what slight additional wear occurs from not using discard,
>> makes the SSD die sooner in order to justify getting a new SSD that
>> maybe (?) doesn't hav
Chris Murphy posted on Thu, 05 Jun 2014 12:13:37 -0600 as excerpted:
>> auto-defrag: not really (read the archives)
>
> Definitely there are some issues, it's probably why its not yet default.
> So I'd either not use it, or use it with the point of testing it to make
> it better.
Usage-pattern i
We have been iterating all references for each extent we have in a file when we
do fiemap to see if it is shared. This is fine when you have a few clones or a
few snapshots, but when you have 5k snapshots suddenly fiemap just sits there
and stares at you. So add btrfs_check_shared which will use
The backref code was looking at nodes as well as leaves when we tried to
populate extent item entries. This is not good, and although we go away with it
for the most part because we'd skip where disk_bytenr != random_memory,
sometimes random_memory would match and suddenly boom. This fixes that p
Timofey Titovets posted on Thu, 05 Jun 2014 19:13:08 +0300 as excerpted:
> 2014-06-05 18:52 GMT+03:00 Igor M :
>> One more question. Is there any other way to find out file
>> fragmentation ?
>> I just copied 35Gb file on new btrfs filesystem (compressed) and
>> filefrag reports 282275 extents fou
On Thu, Jun 05, 2014 at 12:13:37PM -0600, Chris Murphy wrote:
> I'd say, what slight additional wear occurs from not using discard, makes the
> SSD die sooner in order to justify getting a new SSD that maybe (?) doesn't
> have this problem anymore.
Your points are well noted, although on the fli
On Jun 5, 2014, at 9:14 AM, Swâmi Petaramesh wrote:
>> I don't believe that LVM offers any benefit if you use BTRFS.
>
> BTRFS cannot handle swap.
Yes but Fedora's installer doesn't support swapfiles anyway. It only creates
swap partitions (encrypted or not encrypted). And it does allow you t
On Jun 5, 2014, at 8:56 AM, Marc MERLIN wrote:
>
> compression: lzo, not zlib (zlib will slow down your SSD)
I've had mixed results, where benchmarking suggests lzo is faster, but then
zlib actually feels faster. For sure forced zlib compression can be dreadful,
but I kinda expect that and th
On Jun 5, 2014, at 7:30 AM, Swâmi Petaramesh wrote:
> Hi,
>
> I just received a new laptop with a Micron 256GB SSD, and I plan to install
> Fedora 20 onto it.
>
> I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this
> machine, but I'm afraid BTRFS might generate too much w
Le jeudi 5 juin 2014 17:59:48 Christoph Anton Mitterer a écrit :
> Be aware, that discard used with dm-crypt may have security
> implications.
Thanks, I knew :-)
--
Swâmi Petaramesh http://petaramesh.org PGP 9076E32E
Le sage n’est pas celui qui discrimine, c’est celui qui réunit
les lambeaux d
On Thu, Jun 05, 2014 at 05:14:29PM +0200, Swâmi Petaramesh wrote:
> > your laptop is your main desktop system it should get less disk use than a
> > typical workstation.
>
> My laptop (+ docking station) is going to be my daily main machine...
My laptop is my workstation, it's running almost 24/
Am Donnerstag, 5. Juni 2014, 15:30:26 schrieb Swâmi Petaramesh:
> Hi,
>
> I just received a new laptop with a Micron 256GB SSD, and I plan to install
> Fedora 20 onto it.
>
> I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this
> machine, but I'm afraid BTRFS might generate t
2014-06-05 18:52 GMT+03:00 Igor M :
> One more question. Is there any other way to find out file fragmentation ?
> I just copied 35Gb file on new btrfs filesystem (compressed) and
> filefrag reports 282275 extents found. This can't be right ?
hes, because filefrag show compressed block (128kbite) a
On Thu, 2014-06-05 at 07:56 -0700, Marc MERLIN wrote:
> Dmcrypt is
> ok, however add discard to cryptsetup options too
Be aware, that discard used with dm-crypt may have security
implications.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
One more question. Is there any other way to find out file fragmentation ?
I just copied 35Gb file on new btrfs filesystem (compressed) and
filefrag reports 282275 extents found. This can't be right ?
On Thu, Jun 5, 2014 at 5:05 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Igor M posted on Thu, 05 J
Thanks for the reply Russell :-)
Le vendredi 6 juin 2014 00:42:12 Russell Coker a écrit :
>
> Also I think that laptops tend to have less use than workstations, so unless
> your laptop is your main desktop system it should get less disk use than a
> typical workstation.
My laptop (+ docking stat
On Thu, 5 Jun 2014 07:56:32 -0700
Marc MERLIN wrote:
> However SSDs, especially at least earlier models of the one you got, still
> randomly die, and take your data with them.
Yeah, a PSA of sorts: take whatever SSDs you have and use, and go to the
manufacturer's website (right *NOW* :) to check
On Thu, Jun 05, 2014 at 03:30:26PM +0200, Swâmi Petaramesh wrote:
> Hi,
>
> I just received a new laptop with a Micron 256GB SSD, and I plan to install
> Fedora 20 onto it.
>
> I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this
> machine, but I'm afraid BTRFS might generate
On Thu, 5 Jun 2014 15:30:26 Swâmi Petaramesh wrote:
> I just received a new laptop with a Micron 256GB SSD, and I plan to install
> Fedora 20 onto it.
>
> I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this
> machine, but I'm afraid BTRFS might generate too much writes and shor
On Thu, Jun 5, 2014 at 9:41 PM, Marc MERLIN wrote:
> On Thu, Jun 05, 2014 at 12:52:04PM +0100, Tomasz Chmielewski wrote:
>> And it looks the dependency is ~1 GB of new packages? O_o
>
> That seems painful, but at the same time, the alternative, nroff/troff sucks.
>
> Part ofyour problem however se
On Thu, Jun 05, 2014 at 12:52:04PM +0100, Tomasz Chmielewski wrote:
> And it looks the dependency is ~1 GB of new packages? O_o
That seems painful, but at the same time, the alternative, nroff/troff sucks.
Part ofyour problem however seems to be runaway dependencies.
You are getting x11 and stuff
Hi,
I just received a new laptop with a Micron 256GB SSD, and I plan to install
Fedora 20 onto it.
I'm considering either BTRFS or ext4 (over LUKS-encrypted LVM) for this
machine, but I'm afraid BTRFS might generate too much writes and shorten the
SSD lifespan... Or am I mistaken ?
Is there a
On 5/6/2014 10:05 πμ, Liu Bo wrote:
Hi, Konstantinos
On Thu, Jun 05, 2014 at 09:28:16AM +0300, Konstantinos Skarlatos wrote:
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,
I am also getting this...
My system is configured like so:
3.15.0-rc8
Btrfs v3.12
#btrfs fi show
Label: none uuid: e421ceeb-6e4e-4c7e-84b4-6f25442745fa
Total devices 1 FS bytes used 22.51GiB
devid1 size 116.75GiB used 28.02GiB path /dev/sda4
Label: tank uuid: 52044d1c-530
Trying to build the latest btrfs-progs failed form me on Debian 7 with
this:
(...)
[CC] btrfs-show-super.o
[LD] btrfs-show-super
Making all in Documentation
ASCIIDOC btrfs.xml
/bin/sh: 3: asciidoc: not found
make[1]: *** [btrfs.xml] Error 127
make: *** [build-Documentation] E
In inode.c:btrfs_page_exists_in_range(), if the page we get from the
radix tree is an exception which should make us retry, set page to
NULL in order to really retry, because otherwise we don't get another
loop iteration executed (page != NULL makes the while loop exit).
This also was making us cal
In inode.c:btrfs_page_exists_in_range(), if the page we got from
the radix tree is an exception entry, which can't be retried, we
exit the loop with a non-NULL page and then call page_cache_release
against it, which is not ok since it's not a valid page. This could
also make us return true when we
In inode.c:btrfs_page_exists_in_range(), if we can't get the page
we need to retry. However we weren't retrying because we weren't
setting page to NULL, which makes the while loop exit immediately
and will make us call page_cache_release after exiting the loop
which is incorrect because our page ge
On Thu, 5 Jun 2014 09:50:53 Igor M wrote:
> But data to this big tables is only appended, it's never deleted. So
> no rewrites should be happening.
When you write to the big tables the indexes will be rewritten. Indexes can
be in the same file as table data or as separate files depending on what
btrfs filesystem show displays allocated space, but how can userspace
know how much space is used on each device?
In #btrfs channel on freenode.net, it was answered that the
TREE_SEARCH ioctl can be used to inspect the data structures, and that
btrfs-gui does this (thanks @darkling): http://carfax
On Wed, 2014-04-02 at 16:54 +0800, Gui Hecheng wrote:
> For modern filesystems such as btrfs, t/p/e size level operations
> are common.
> add size unit t/p/e parsing to memparse
>
> Signed-off-by: Gui Hecheng
> ---
> changelog
> v1->v2: replace kilobyte with kibibyte, and others
> v2-
David Sterba on Wed, 2014/06/04 18:44:
> 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" al
Erkki Seppala writes:
> If the number is hitting your seek rate (ie. 1/0.0075 for 7.5 ms seek =
> 133), then fragmentation is sure to be blamed.
Actually the number may very well be off by at least a factor of two (I
tested that my device did 400 tps when I expected 200; perhaps bulk
transfers c
gcc 4.9.0 gives warnings about possibly uninitialized values when
compiling with function inlining and optimization level two enabled
(CFLAGS="-finline-functions -O2").
Initializing the values fixes the warning. Hope this is correct.
Signed-off-by: Christian Hesse
---
cmds-send.c | 2 +-
send
Igor M writes:
> Why btrfs becames EXTREMELY slow after some time (months) of usage ?
Have you tried iostat from sysstat to see the number of IO-operations
performed per second (tps) on the devices when it is performing badly?
If the number is hitting your seek rate (ie. 1/0.0075 for 7.5 ms see
On Thu, Jun 05, 2014 at 10:05:19AM +0800, Gui Hecheng wrote:
> Based on Documentation/filesystems/btrfs.txt
>
> Signed-off-by: Gui Hecheng
> ---
> sys-utils/mount.8 | 186
> ++
> 1 file changed, 186 insertions(+)
Thanks, but I'm not sure thi
Thanks for explanation. I did read wiki, but didn't see this mentioned.
I saw mentioned 'nodatacow' mount option, but this disables
compression and I need compression.
Also I was wrong about files size, files can go to 70GB.
But data to this big tables is only appended, it's never deleted. So
no re
Hi, Konstantinos
On Thu, Jun 05, 2014 at 09:28:16AM +0300, Konstantinos Skarlatos wrote:
> 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 creat
50 matches
Mail list logo
