Hi all,
one friend published a comparison of FS with compression. I'm sharing
here in case anyone is interested
https://lab.nethence.com/fsbench/2022-10.html
Cheers,
Yadd
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: golang-github-dennwc-btrfs
Version : 0.0~git20220403.b3db0b2
Upstream Author : Denys Smirnov
* URL : https://github.com/dennwc/btrfs
* License
On Fri, 2022-08-26 at 11:05 +0200, John Paul Adrian Glaubitz wrote:
> To workaround a longstanding qemu/glibc compatibility issue [2], I need
> the images to use btrfs instead of ext4 and I was wondering whether anyone
> can give me some hints on how to convert the images provided at
(I'm not subscribed to the list, please CC me. Thanks!)
Hello!
I'm using Debian's OpenStack images to deploy buildd hosts for Debian
Ports. [1]
To workaround a longstanding qemu/glibc compatibility issue [2], I need
the images to use btrfs instead of ext4 and I was wondering whe
: C++
Description : Best-Effort Extent-Same, a btrfs deduplication agent.
bees is a block-oriented userspace deduplication agent designed for
large btrfs filesystems. It is an offline dedupe combined with an
incremental data scan capability to minimize time data spends on disk
from write
+
Programming Lang: C++
Description : a btrfs deduplication agent
Best-Effort Extent-Same, a btrfs deduplication agent.
bees is a block-oriented userspace deduplication agent designed for large
btrfs filesystems. It is an offline dedupe combined with an incremental data
scan capability to minimize time
Description : converts NTFS filesystem to BTRFS
This is a tool which does in-place conversion of Microsoft's NTFS
filesystem
to the open-source filesystem Btrfs, much as btrfs-convert does for
ext2.
The original image is saved as a reflink copy at image/ntfs.img, and if
you
want to kee
Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves
Control: block -1 by #840248
Package name: grub-btrfs
Version : 4.1
Upstream Author : Antynea
URL : https://github.com/Antynea/grub-btrfs
License : GPL-3+
Programming Lang: bash
Description : GRUB
clone 886968 -1
retitle -1 debhelper: Make -V the default for dh_makeshlibs
severity -1 wishlist
tags -1 patch
thanks
Emilio Pozuelo Monfort:
> [...]
>
> It's not in policy (but I don't think it has to be), but following the
> conversation on #-ftp yesterday I opened:
>
> #895949 lintian: warn a
Hello,
Dimitri John Ledkov (2018-04-20):
> From my point of view, this is confusing... cause I regard myself as
> being part of the installer team myself.
>
> I guess you are advocating for general code review, more than two
> pairs of eyes on things?
There were no mails on debian-boot@, so tha
On 18 April 2018 at 08:18, Emilio Pozuelo Monfort wrote:
> On 18/04/18 01:30, Cyril Brulebois wrote:
>> That's another perfect example why udeb additions should get reviewed:
>> we would have noticed another buggy package, and its bugginess might not
>> have been copied over to another package.
>
eded.
>
>> Secondly, my work has been blocked by this NEW processing too for
>> btrfs-progs. I'm not aware as to which Helmut's work was blocked,
>> could you please elaborate what Helmut is blocked on? And/or how can
>> libzstd/me help to unblock Helmut? -> is that
On 18/04/18 01:30, Cyril Brulebois wrote:
> That's another perfect example why udeb additions should get reviewed:
> we would have noticed another buggy package, and its bugginess might not
> have been copied over to another package.
I'm sure people don't request those reviews because they don't k
Hi,
Dimitri John Ledkov (2018-04-17):
> First, I apologize for not responding to this email earlier, as I have
> missed it in my mailbox.
It's a mail from hours ago, so there's no apology needed.
> Secondly, my work has been blocked by this NEW processing too for
> btrf
On 17 April 2018 at 19:01, Cyril Brulebois wrote:
> Dimitri John Ledkov (2018-01-15):
>> On 15 January 2018 at 00:27, Cyril Brulebois wrote:
>> > Hi,
>> >
>> > Cyril Brulebois (2018-01-12):
>> >> Your package is no longer installable (along with
Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout
* Package name: golang-github-containerd-btrfs
Version : 0.0~git20171005.72c0a35-1
Upstream Author : containerd
* URL : https://github.com/containerd/btrfs
* License : Apache-2.0
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout
* Package name: golang-github-containerd-btrfs
Version : 0.0~git20171005.72c0a35-1
Upstream Author : containerd
* URL : https://github.com/containerd/btrfs
* License : Apache-2.0
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Adam Borowski
* Package name: btrfs-compsize
Upstream Author : me, Timofey Titovets
* URL : https://github.com/kilobyte/compsize
* License : GPL2+
Programming Lang: C
Description : calculate compression ratio of a set of
Package: wnpp
Severity: wishlist
Owner: Hans van Kranenburg
* Package name: btrfs-heatmap
Version : 6
Upstream Author : Hans van Kranenburg
* URL : https://github.com/knorrie/btrfs-heatmap/
* License : GPL-2
Programming Lang: Python 3
Description
Package: wnpp
Severity: wishlist
Owner: Hans van Kranenburg
* Package name: python-btrfs
Version : 6
Upstream Author : Hans van Kranenburg
* URL : https://github.com/knorrie/python-btrfs/
* License : GPL-2
Programming Lang: Python 3
Description
Am 2016-07-10 16:10, schrieb Marc Haber:
I have severe allocation issues in btrfs with recent kernels and
recent btrfs-tools when using thousands of snapshots. All the
community had to offer was "well, try to restrict yourself to at most
a few hundred snapshots".
btrfs rebalance
On Mon, 11 Jul 2016 22:29:20 +0200, Philipp Kern
wrote:
>On Mon, Jul 11, 2016 at 08:07:20PM +0200, Marc Haber wrote:
>> [1] I remember the day when a Debian stable point release introduced a
>> new version of an ethernet driver that broke an entire class of IBM
>> blade servers' networks and I als
On Mon, Jul 11, 2016 at 09:12:43AM +0100, Dimitri John Ledkov wrote:
> On 11 July 2016 at 04:07, wrote:
> >>Say what you want.
> >
> > Now I want to know if Debian Stable can in some extreme cases, like in
> > this case with btrfs, replace not_very_good kernel modul
On Mon, Jul 11, 2016 at 08:07:20PM +0200, Marc Haber wrote:
> [1] I remember the day when a Debian stable point release introduced a
> new version of an ethernet driver that broke an entire class of IBM
> blade servers' networks and I also remember being scolded for relying
> on Debian stable inste
On Mon, 11 Jul 2016 05:07:12 +0200, german...@ya.ru wrote:
>Now I want to know if Debian Stable can in some extreme cases, like in this
>case with btrfs, replace
>not_very_good kernel module that is shipped with its current kernel with a
>kernel module from other (older or newer
* german...@ya.ru [160710 23:08]:
> Now I want to know if Debian Stable can in some extreme cases, like in
> this case with btrfs, replace not_very_good kernel module that is
> shipped with its current kernel with a kernel module from other (older
> or newer) version of Linux kerne
On 11 July 2016 at 04:07, wrote:
>>Say what you want.
>
> Now I want to know if Debian Stable can in some extreme cases, like in this
> case with btrfs, replace
> not_very_good kernel module that is shipped with its current kernel with a
> kernel module from other (older
❦ 11 juillet 2016 05:07 CEST, german...@ya.ru :
>>Say what you want.
>
> Now I want to know if Debian Stable can in some extreme cases, like in this
> case with btrfs, replace
> not_very_good kernel module that is shipped with its current kernel
> with a kernel module from
>Say what you want.
Now I want to know if Debian Stable can in some extreme cases, like in this
case with btrfs, replace
not_very_good kernel module that is shipped with its current kernel with a
kernel module from other (older or newer) version of Linux kernel and if yes,
is it the case w
On Sun, 10 Jul 2016 09:39:03 +0300, Otto Kekäläinen
wrote:
>Yes, btrfs in kernel 3.16-18 might still be unstable, but since then
>it is got some important fixes, it is production ready and is actually
>pretty amazing in many ways.
I have severe allocation issues in btrfs with recent ke
On Sun, 10 Jul 2016 10:10:19 +0200, german...@ya.ru wrote:
>But does Debian Stable have this new and relatively stable version of btrfs or
>it just uses old and not_so_stable version from 3.16 version of Linux kernel?
Stop ranting.
Say what you want. And while you're at it, think ab
>Yes, btrfs in kernel 3.16-18 might still be unstable, but since then
>it is got some important fixes, it is production ready and is actually
>pretty amazing in many ways.
But does Debian Stable have this new and relatively stable version of btrfs or
it just uses old and not_so_stabl
ocumentation for version of a Linux kernel of Debian
> Stable and it says that btrfs is under heavy development and isn't suitable
> for any uses other than benchmarking and review. Proof-link:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentatio
On Sat, 09 Jul 2016 03:55:31 +0200, german...@ya.ru wrote:
>But if btrfs is so unstable, then what the hell it's doing in Debian Stable's
>kernel?
Because people might want to try it.
Grüße
Marc
--
-- !! No courtesy copies, please !!
case here. At the least for Debian Installer, it
> doesn't have any warning like "Use btrfs on your own risk, it
> currently considered as experimental and unstable".
Please file a bugreport against debian-installer, then.
This in not the place to discuss specific bugs.
- Jona
Quoting german...@ya.ru (2016-07-09 10:15:54)
> But I have read in Debian's documentation that some pieces of software
> can be excluded from Debian if they're considered too buggy. Isn't it
> the case for exclusion of highly experimental and immature programs
>
>What would be troublesome was if Debian enabled any dangerous options by
>default or promoted them too prominently without adequate warnings.
>That does not seem to be the case here.
It seems to be the case here. At the least for Debian Installer, it doesn't
have any warning l
But I have read in Debian's documentation that some pieces of software can be
excluded from Debian if they're considered too buggy. Isn't it the case for
exclusion of highly experimental and immature programs like btrfs for Linux
3.16 ?
Quoting german...@ya.ru (2016-07-09 04:29:58)
> >Believe the upstream. While in the nearest kernel, there is no sentence
> >about "under heavy
> development". Installer is just installer.
>
> It doesn't matter if the latest stable Linux kernel has stable and m
Debian includes btrfs module. But documentation for this version of kernel
> says that "Btrfs is under heavy development, and is not suitable for
> any uses other than benchmarking and review. The Btrfs disk format is not yet
> finalized." (Proof-link:
> https://git.kernel.o
Probably my previous message was misunderstood, so I try to rephrase it.
Current Debian Stable is Debian Jessie. The latest Linux kernel for Debian
Jessie is 3.16. The said version of Linux kernel on the said version of Debian
includes btrfs module. But documentation for this version of kernel
On Sat, 09 Jul 2016, german...@ya.ru wrote:
> >If you are very conservative on these matters, your two choices are ext4 and
> >XFS.
>
> I don't want XFS because it has weak journaling compared with "data=journal"
> mode of ext3/4.
The data=journal mode of ext4 is less stable than the default
da
>Believe the upstream. While in the nearest kernel, there is no sentence about
>"under heavy
development". Installer is just installer.
It doesn't matter if the latest stable Linux kernel has stable and mostly
bug-free btrfs. The problem is, that the latest stable Linux k
>If you are very conservative on these matters, your two choices are ext4 and
>XFS.
I don't want XFS because it has weak journaling compared with "data=journal"
mode of ext3/4.
I tried to use ext4 on Debian Stable due to metadata checksums, but then
discovered that e2fsck doesn't support this
>Please don't use btrfs. Especially not without understanding fully
what one is getting oneself into. It is checksuming, copy of write
filesystem, however it has degrading over time performance and
stability/recovery issues.
But if btrfs is so unstable, then what the hell it's do
Marco d'Itri wrote:
> On Jul 08, Russ Allbery wrote:
> > And of those two choices, I would lean heavily towards ext4. I have seen
> > repeated file system corruptions, kernel panics, and file systems that get
> > extremely slow after heavy usage for multiple months under XFS, and have
> > not see
hand I read documentation for version of a Linux kernel of Debian
> Stable and it says that btrfs is under heavy development and isn't suitable
> for any uses other than benchmarking and review. Proof-link:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree
On Jul 08, Russ Allbery wrote:
> And of those two choices, I would lean heavily towards ext4. I have seen
> repeated file system corruptions, kernel panics, and file systems that get
> extremely slow after heavy usage for multiple months under XFS, and have
> not seen any of those problems with
Henrique de Moraes Holschuh writes:
> On Fri, 08 Jul 2016, german...@ya.ru wrote:
>> I value stability of a FS over other considerations like shiny new
>> features and performance. I know that Debian Stable includes only that
> Then, your case is pretty clear: stay away from brtfs. If you are v
On Fri, 08 Jul 2016, german...@ya.ru wrote:
> I value stability of a FS over other considerations like shiny new
> features and performance. I know that Debian Stable includes only that
Then, your case is pretty clear: stay away from brtfs. If you are very
conservative on these matters, your two
ion for version of a Linux
>kernel of Debian Stable and
>it says that btrfs is under heavy development and isn't suitable for any uses
>other than benchmarking
>and review. Proof-link:
>https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation
hand I read documentation for version of a Linux kernel of Debian
> Stable and it says that btrfs is under heavy development and isn't suitable
> for any uses other than benchmarking and review. Proof-link:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree
Stable and it says
that btrfs is under heavy development and isn't suitable for any uses other
than benchmarking and review. Proof-link:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/btrfs.txt?id=refs/tags/v3.16.36
I'm really c
On Sat, 06 Feb 2016 16:06:15 +0200, Ioan Eugen Stan
wrote:
> Each of the tasks can be turned on/off and configured independently. The
> default config values were selected to fit the default installation profile of
> openSUSE 13.2 where the root filesystem is formatted to btrfs. Su
Package: wnpp
Severity: wishlist
Owner: Ioan Eugen Stan
* Package name: btrfsmaintenance
Version : 0.1.2
Upstream Author : Dave
* URL : https://github.com/kdave/btrfsmaintenance
* License : GPL2
Programming Lang: shell
Description : Btrfs maintenance
Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko
* Package name: btrbk
Version : 0.19.3
Upstream Author : Axel Burri
* URL : http://www.digint.ch/btrbk/
* License : GPL
Programming Lang: Perl, Bash
Description : Backup tool for btrfs volumes
Not a user of btrfs, but the userspace tools are in package btrfs-tools
https://packages.debian.org/search?keywords=btrfs-tools
and the kernel modules seem to be in the default kernel packages
$ dpkg -L linux-image-3.2.0-4-amd64 | grep btrfs.ko
/lib/modules/3.2.0-4-amd64/kernel/fs/btrfs/btrfs.ko
hello
searching on packages.debian.org shows btrfs only for testing, oldstable,
NOT in stable? how that?!
please also CC me (not in mailinglist)
thanks
Andrew
Processing control commands:
> severity -1 normal
Bug #741893 [general] general: System unresponsive after large torrent download
to btrfs
Severity set to 'normal' from 'important'
> reassign -1 src:linux
Bug #741893 [general] general: System unresponsive after large
control: severity -1 normal
control: reassign -1 src:linux
# I believe it's btrfs to blame, but maybe it's transmission?
thanks
On Montag, 17. März 2014, Mike wrote:
> Package: general
> Severity: important
>
> Dear Maintainer,
>
> Downloading a large torre
Package: general
Severity: important
Dear Maintainer,
Downloading a large torrent (30GB, 1 files) using transmission-gtk
onto a btrfs filesystem (mounted as the root filesystem) causes the system to
become unresponsive after a very short period of time. Tried marking the
torrent
On Thu, Dec 13, 2012 at 09:43:20AM -0700, Aaron Toponce wrote:
> Recently, I decided to put down a Btrfs root on my workstation using the
> latest release of the installer. I found that given my hardware
> configuration, this is not possible, and would require using another
>
Recently, I decided to put down a Btrfs root on my workstation using the
latest release of the installer. I found that given my hardware
configuration, this is not possible, and would require using another
installer or debootstrap the installation, which is far from ideal.
I have two 250 GB
On Tue, Dec 28, 2010 at 21:53, Aron Xu wrote:
> Package: btrfs-tools
> Version: 0.19+20100601-3, 0.19+20101101-1
> Severity: serious
>
> Balance tree action of btrfs command should be limited to only root
> user, because it may cause data corrupt and usually result in an
> un
On Wed, Oct 14, 2009 at 09:41:22PM +0200, Sven Arvidsson wrote:
> Have you reported this as a bug upstream so proper quirks can be
> added?
Not yet, as I was only just this week able to easily test KMS (now
that it works with PAE in an official Linux kernel release packaged
for Debian). Support fo
On Wed, 2009-10-14 at 16:12 +, The Fungi wrote:
> Yes, this has been working for me with 2.6.31 (putting
> GRUB_CMDLINE_LINUX_DEFAULT="video=i915:modeset=1" in
> /etc/default/grub, to be specific). Still waiting to be able to add
> custom modelines at boot since my HDTV outputs bogus EDID info
On Wed, Oct 14, 2009 at 05:56:27PM +0200, Luca Niccoli wrote:
> Pass modeset=1 as a parameter to the module.
Yes, this has been working for me with 2.6.31 (putting
GRUB_CMDLINE_LINUX_DEFAULT="video=i915:modeset=1" in
/etc/default/grub, to be specific). Still waiting to be able to add
custom modeli
2009/10/7 The Fungi :
> Now if only it had CONFIG_DRM_I915_KMS
Pass modeset=1 as a parameter to the module.
Cheers,
Luca
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Thu, 2009-10-08 at 11:51 +1100, Russell Coker wrote:
> On Thu, 8 Oct 2009, Ben Hutchings wrote:
> > That package is currently called firmware-linux but will be renamed
> > shortly because we now also package the DFSG-free firmware from the
> > Linux tree as firmware-linux-free. (firmware-linux
lot for this advice! Strangely installing the firmware-linux package
on 2.6.30 caused a kernel panic (I didn't expect it to do anything with the
current kernel as it only applied to 2.6.31). But I then booted into 2.6.31
without any problems.
I now have a test system running btrfs with a few g
ok to ...". As I read it, he's not expecting them to
> > do anything *more* than they already do, just to relax the protection
> > argument a little when it comes to people who are already aiming at
> > their feet.
>
> Yes. Also anyone who really wants their dat
On Wed, Oct 07, 2009 at 03:10:27PM +, The Fungi wrote:
[...]
> ...so I guess just adding i915.modeset=1 to the kernel command line
> should make it go.
[...]
Just to follow up, Sven Arvidsson confirmed over on intel-...@lfdo
that video=i915:modeset=1 on the kernel command line coupled with
ini
On Wed, 2009-10-07 at 15:10 +, The Fungi wrote:
> On Wed, Oct 07, 2009 at 04:40:09PM +0200, Mike Hommey wrote:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521596#10
> >
> > I don't remember how to enable it, though.
>
> I do see this this in the changelog for 2.6.29-1:
>
> * [x86] u
On Wed, Oct 07, 2009 at 04:40:09PM +0200, Mike Hommey wrote:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521596#10
>
> I don't remember how to enable it, though.
I do see this this in the changelog for 2.6.29-1:
* [x86] unset DRM_I915_KMS due to upgrade path from Lenny override
with modes
On Wed, Oct 07, 2009 at 02:24:36PM +, The Fungi wrote:
> On Thu, Oct 08, 2009 at 12:01:13AM +1100, Russell Coker wrote:
> [...]
> > But it has been pointed out a few times (including a couple of
> > private messages) that experimental has what I desire (thanks for
> > the advice everyone).
> [.
stem with
> mkfs.btrfs and can't mount it is obviously not ideal. Of course with this
> type of change if the upload of the btrfs-tools had been delayed so that the
> kernel got in first then we would STILL have had the same situation (I
> believe that there was neither forward nor ba
On Thu, Oct 08, 2009 at 12:01:13AM +1100, Russell Coker wrote:
[...]
> But it has been pointed out a few times (including a couple of
> private messages) that experimental has what I desire (thanks for
> the advice everyone).
[...]
Now if only it had CONFIG_DRM_I915_KMS and CONFIG_HID_WACOM enable
hing *more* than they already do, just to relax the protection
> argument a little when it comes to people who are already aiming at
> their feet.
Yes. Also anyone who really wants their data to be safe won't use Unstable
anyway.
BTRFS is a little different to most kernel features, it
2009/10/7 Josselin Mouette :
> Le mercredi 07 octobre 2009 à 14:12 +1100, Russell Coker a écrit :
>> I expect that the kernel team tends to be more careful about uploads to
>> Unstable than most package maintainers due to the scope of damage that a bad
>> kernel can cause.
>
> I think it is unreaso
I think it's reasonable for package maintainers to check compatibility
with the kernel from the
distribution they upload package to. Especialy here when package is
newer then kernel driver.
It's of course harder to supervise the situation when kernel pass
ahead of user-space packages
but it's also
Le mercredi 07 octobre 2009 à 14:12 +1100, Russell Coker a écrit :
> I expect that the kernel team tends to be more careful about uploads to
> Unstable than most package maintainers due to the scope of damage that a bad
> kernel can cause.
I think it is unreasonable to ask them to check interac
> kernel for people who want to test btrfs? I'm assuming that every system
> that runs btrfs is at risk of losing all it's data anyway so running an
> experimental kernel isn't going to make things any riskier.
Is 2.6.31 enoiugh?
cor...@hidalgo: apt-cache search linux-
Last night I tried to get btrfs working on a test machine. It seems that in
Unstable mkfs.btrfs has been updated to the latest disk format, but the
latest kernel image that is available only supports the old format.
I expect that the kernel team tends to be more careful about uploads to
83 matches
Mail list logo
