Russell Coker wrote on 2015/12/02 17:25 +1100:
On Wed, 2 Dec 2015 06:05:09 AM Eric Sandeen wrote:
yes, xfs does; we have "-o norecovery" if you don't want that, or need
to mount a filesystem with a dirty log on a readonly device.
That option also works with Ext3/4 so it seems to be a standar
kernel BUG at fs/btrfs/extent-tree.c:1833!
invalid opcode: [#1] SMP
Modules linked in: xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4
tun nls_utf8 isofs rfcomm fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack ebtable_nat ebtable_brout
Qu Wenruo wrote on 2015/12/02 17:06 +0800:
Russell Coker wrote on 2015/12/02 17:25 +1100:
On Wed, 2 Dec 2015 06:05:09 AM Eric Sandeen wrote:
yes, xfs does; we have "-o norecovery" if you don't want that, or need
to mount a filesystem with a dirty log on a readonly device.
That option also
What are your disk space savings when using btrfs with compression?
I have a 200 GB btrfs filesystem which uses compress=zlib, only stores
text files (logs), mostly multi-gigabyte files.
It's a "single" filesystem, so "df" output matches "btrfs fi df":
# df -h
Filesystem Size Used Avai
Gareth Pye posted on Wed, 02 Dec 2015 18:07:48 +1100 as excerpted:
> Output from scrub:
> sudo btrfs scrub start -Bd /data
[Omitted no-error device reports.]
> scrub device /dev/sdh (id 6) done
>scrub started at Wed Dec 2 07:04:08 2015 and finished after 06:47:22
>total bytes scrubbed:
Tomasz Chmielewski posted on Wed, 02 Dec 2015 18:46:30 +0900 as excerpted:
> What are your disk space savings when using btrfs with compression?
>
> I have a 200 GB btrfs filesystem which uses compress=zlib, only stores
> text files (logs), mostly multi-gigabyte files.
>
>
> It's a "single" fil
Thanks for that info, ram appears to be checking out fine and smartctl
reported that the drives are old but one had some form of elevated
error. Looks like I might be buying a new drive.
On Wed, Dec 2, 2015 at 9:01 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Gareth Pye posted on Wed, 02 Dec 2015 18
On 2015-12-02 05:01, Duncan wrote:
Gareth Pye posted on Wed, 02 Dec 2015 18:07:48 +1100 as excerpted:
Output from scrub:
sudo btrfs scrub start -Bd /data
[Omitted no-error device reports.]
scrub device /dev/sdh (id 6) done
scrub started at Wed Dec 2 07:04:08 2015 and finished after 06:
On 2015-12-02 04:46, Tomasz Chmielewski wrote:
What are your disk space savings when using btrfs with compression?
I have a 200 GB btrfs filesystem which uses compress=zlib, only stores
text files (logs), mostly multi-gigabyte files.
It's a "single" filesystem, so "df" output matches "btrfs fi
Russell Coker posted on Wed, 02 Dec 2015 17:42:15 +1100 as excerpted:
> On Mon, 9 Nov 2015 08:10:13 AM Duncan wrote:
>> Russell Coker posted on Sun, 08 Nov 2015 17:38:32 +1100 as excerpted:
>> > https://lwn.net/Articles/663474/
>> > http://thread.gmane.org/gmane.comp.file-systems.btrfs/49500
>> >
Austin S Hemmelgarn posted on Wed, 02 Dec 2015 07:25:13 -0500 as
excerpted:
> On 2015-12-02 05:01, Duncan wrote:
[on unverified errors returned by scrub]
>>
>> Unverified errors are, I believe[1], errors where a metadata block
>> holding checksums itself has an error, so the blocks its checksums
On 2015-12-02 22:03, Austin S Hemmelgarn wrote:
From these numbers (124 GB used where data size is 153 GB), it
appears
that we save around 20% with zlib compression enabled.
Is 20% reasonable saving for zlib? Typically text compresses much
better
with that algorithm, although I understand th
>> What are your disk space savings when using btrfs with compression?
> * There's the compress vs. compress-force option and discussion. A
> number of posters have reported that for mostly text, compress didn't
> give them expected compression results and they needed to use compress-
> force.
"
On 2015-12-02 23:03, Wang Shilong wrote:
Compression ratio is much much better now (on a slightly changed data
set):
# df -h
/dev/xvdb 200G 24G 176G 12% /var/log/remote
# du -sh /var/log/remote/
138G/var/log/remote/
So, 138 GB files use just 24 GB on disk - nice!
However, I
On Wed, Dec 2, 2015 at 9:53 PM, Tomasz Chmielewski wrote:
> On 2015-12-02 22:03, Austin S Hemmelgarn wrote:
>
>>> From these numbers (124 GB used where data size is 153 GB), it appears
>>> that we save around 20% with zlib compression enabled.
>>> Is 20% reasonable saving for zlib? Typically text
On 2015-12-02 08:45, Duncan wrote:
Austin S Hemmelgarn posted on Wed, 02 Dec 2015 07:25:13 -0500 as
excerpted:
On 2015-12-02 05:01, Duncan wrote:
[on unverified errors returned by scrub]
Unverified errors are, I believe[1], errors where a metadata block
holding checksums itself has an error
On 2015-12-02 09:03, Imran Geriskovan wrote:
What are your disk space savings when using btrfs with compression?
* There's the compress vs. compress-force option and discussion. A
number of posters have reported that for mostly text, compress didn't
give them expected compression results and
On 2015-12-02 08:53, Tomasz Chmielewski wrote:
On 2015-12-02 22:03, Austin S Hemmelgarn wrote:
From these numbers (124 GB used where data size is 153 GB), it appears
that we save around 20% with zlib compression enabled.
Is 20% reasonable saving for zlib? Typically text compresses much better
On 12/2/15 3:23 AM, Qu Wenruo wrote:
>
>
> Qu Wenruo wrote on 2015/12/02 17:06 +0800:
>>
>>
>> Russell Coker wrote on 2015/12/02 17:25 +1100:
>>> On Wed, 2 Dec 2015 06:05:09 AM Eric Sandeen wrote:
yes, xfs does; we have "-o norecovery" if you don't want that, or need
to mount a filesyst
On Wed, Dec 2, 2015 at 9:18 AM, Михаил Гаврилов
wrote:
> kernel BUG at fs/btrfs/extent-tree.c:1833!
> invalid opcode: [#1] SMP
> Modules linked in: xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4
> tun nls_utf8 isofs rfcomm fuse nf_conntrack_netbios_ns
> nf_conntrack_broadcast ip6t_rpfilter
On Wed, Dec 2, 2015 at 1:27 AM, Christoph Hellwig wrote:
> Hi Steve,
>
> we have two APIs in Linux:
>
> - the copy_file_range syscall which just is a "do a copy by any means"
> - the btrfs clone ioctls which have stricter semantics that very much
>expect a reflink-like operation
If the copy
On 2015-12-02 11:54, Eric Sandeen wrote:
On 12/2/15 3:23 AM, Qu Wenruo wrote:
Qu Wenruo wrote on 2015/12/02 17:06 +0800:
Russell Coker wrote on 2015/12/02 17:25 +1100:
On Wed, 2 Dec 2015 06:05:09 AM Eric Sandeen wrote:
yes, xfs does; we have "-o norecovery" if you don't want that, or need
On Wed, Dec 02, 2015 at 12:48:39PM -0500, Austin S Hemmelgarn wrote:
> On 2015-12-02 11:54, Eric Sandeen wrote:
> >On 12/2/15 3:23 AM, Qu Wenruo wrote:
> >>Qu Wenruo wrote on 2015/12/02 17:06 +0800:
> >>>Russell Coker wrote on 2015/12/02 17:25 +1100:
> On Wed, 2 Dec 2015 06:05:09 AM Eric Sandee
On 2015-12-02 00:43, Qu Wenruo wrote:
[...]
>
> And block layer provides its own listen interface, reporting errors
> like ATA error.
Could you point me to this kind of interface
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
just saw this in the logs on a few machines, Kernel 4.3.0, Mount options:
/dev/sda /media/storage1 btrfs
rw,noatime,compress=lzo,space_cache,subvolid=5,subvol=/ 0 0
[414675.258270] INFO: task java:19267 blocked for more than 120 seconds.
[414675.258312] Not tainted 4.3.0-040300-generic
Yeah having a scrub take 9 hours instead of 24 (+ latency of human
involvement) would be really nice.
On Thu, Dec 3, 2015 at 1:32 AM, Austin S Hemmelgarn
wrote:
> On 2015-12-02 08:45, Duncan wrote:
>>
>> Austin S Hemmelgarn posted on Wed, 02 Dec 2015 07:25:13 -0500 as
>> excerpted:
>>
>>> On 2015
On 12/2/15 11:48 AM, Austin S Hemmelgarn wrote:
> On a side note, do either XFS or ext4 support removing the norecovery
> option from the mount flags through mount -o remount? Even if they
> don't, that might be a nice feature to have in BTRFS if we can safely
> support it.
It's not remountable
On 12/03/2015 03:07 AM, Goffredo Baroncelli wrote:
On 2015-12-02 00:43, Qu Wenruo wrote:
[...]
And block layer provides its own listen interface, reporting errors
like ATA error.
Could you point me to this kind of interface
Not yet, and that's the problem...
Thanks,
Qu
--
To unsubscribe
On 12/03/2015 06:48 AM, Eric Sandeen wrote:
On 12/2/15 11:48 AM, Austin S Hemmelgarn wrote:
On a side note, do either XFS or ext4 support removing the norecovery
option from the mount flags through mount -o remount? Even if they
don't, that might be a nice feature to have in BTRFS if we can
On Thu, Dec 03, 2015 at 07:40:08AM +0800, Qu Wenruo wrote:
>
>
> On 12/03/2015 06:48 AM, Eric Sandeen wrote:
> >On 12/2/15 11:48 AM, Austin S Hemmelgarn wrote:
> >
> >>On a side note, do either XFS or ext4 support removing the norecovery
> >>option from the mount flags through mount -o remount?
Austin S Hemmelgarn posted on Wed, 02 Dec 2015 09:39:08 -0500 as
excerpted:
> On 2015-12-02 09:03, Imran Geriskovan wrote:
What are your disk space savings when using btrfs with compression?
>>
>>> [Some] posters have reported that for mostly text, compress didn't
>>> give them expected compr
Hugo Mills posted on Wed, 02 Dec 2015 23:51:55 + as excerpted:
> On Thu, Dec 03, 2015 at 07:40:08AM +0800, Qu Wenruo wrote:
>>
>> Not remountable is very good to implement it.
>> Makes things super easy to do.
>>
>> Or we will need to add log replay for remount time.
>>
>> I'd like to imple
33 matches
Mail list logo
