Re: compression disk space saving - what are your results?

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

Re: compression disk space saving - what are your results?

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

Re: utils version and convert crash

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

Re: vfs: move btrfs clone ioctls to common code

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

Re: Bug/regression: Read-only mount not read-only

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

Re: kernel BUG at fs/btrfs/extent-tree.c:1833! [btrfs]

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 >

Re: Bug/regression: Read-only mount not read-only

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

Re: [RFC] Btrfs device and pool management (wip)

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

Subvolume UUID

-- 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

Re: Bug/regression: Read-only mount not read-only

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

Re: Bug/regression: Read-only mount not read-only

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

kernel BUG at fs/btrfs/extent-tree.c:1833! [btrfs]

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

Re: Bug/regression: Read-only mount not read-only

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

Bug Report: btrfs hangs / freezes on 4.3

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

Re: utils version and convert crash

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 >>

Re: Bug/regression: Read-only mount not read-only

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

Re: Bug/regression: Read-only mount not read-only

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

Re: compression disk space saving - what are your results?

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

Re: Bug/regression: Read-only mount not read-only

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?

Re: Bug/regression: Read-only mount not read-only

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

Re: [RFC] Btrfs device and pool management (wip)

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

compression disk space saving - what are your results?

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

Re: utils version and convert crash

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:

Re: compression disk space saving - what are your results?

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"

Re: utils version and convert crash

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

Re: utils version and convert crash

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

Re: compression disk space saving - what are your results?

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

Re: LWN mention

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 >> >

Re: utils version and convert crash

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

Re: compression disk space saving - what are your results?

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

Re: compression disk space saving - what are your results?

>> 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.

Re: compression disk space saving - what are your results?

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

Re: compression disk space saving - what are your results?

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