Re: BTRFS free space handling still needs more work: Hangs again
On 2014-12-28 01:25, Robert White wrote: On 12/27/2014 08:01 AM, Martin Steigerwald wrote: From how you write I get the impression that you think everyone else beside you is just silly and dumb. Please stop this assumption. I may not always get terms right, and I may make a mistake as with the wrong df figure. But I also highly dislike to feel treated like someone who doesn´t know a thing. Nope. I'm a systems theorist and I demand/require variable isolation. Not a question of silly or dumb but a question of speaking with sufficient precision and clarity. For instance you speak of having an impression and then decide I've made an assumption. I define my position. Explain my terms. Give my examples. I also risk being utterly wrong because sometimes being completely wrong gets others to cut away misconceptions and assumptions. It annoys some people, but it gets results. Can you please stop this bullshit posturing nonsense? It accomlishes nothing -- if you're right your other posts will stand for themselves and show that you are indeed the shit when it comes to these matters, but this post (so far, didn't read further) accomplishes nothing other than (possibly) convincing everyone that you're a pompous/self-important ass. Regards, -- 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: [RFC PATCH] Btrfs: add sha256 checksum option
On 2014-11-25 17:47, David Sterba wrote: On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote: On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li@oracle.com wrote: This brings a strong-but-slow checksum algorithm, sha256. Actually btrfs used sha256 at the early time, but then moved to crc32c for performance purposes. As crc32c is sort of weak due to its hash collision issue, we need a stronger algorithm as an alternative. Users can choose sha256 from mkfs.btrfs via $ mkfs.btrfs -C 256 /device Agree with others about -C 256...-C sha256 is only three letters more ;) What's the target for this mode? Are we trying to find evil people scribbling on the drive, or are we trying to find bad hardware? We could provide an interface for external applications that would make use of the strong checksums. Eg. external dedup, integrity db. The benefit here is that the checksum is always up to date, so there's no need to compute the checksums again. At the obvious cost. Yes, pleease! Regards, -- 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: btrfs send and an existing backup
On 2014-11-19 16:58, Jakob Schürz wrote: Hi there! I'm new on btrfs, and I like it :) But i have a question. I have a existing backup on an external HDD. This was ext4 before i converted it to btrfs. And i installed my debian new on btrfs with some subvolumes. (f.e. home, var, multimedia/Video multimedia/Audio...) If you have no other backups, I would really recommend that you *don't* use btrfs for your backup, or at least have a *third* backup which isn't on btrfs -- there are *still* problems with btrfs that can potentially wreck your backup filesystem. (Although it's obviously less likely if the external HDD will only be connected occasionally.) Don't get me wrong, btrfs is becoming more and more stable, but I wouldn't trust it with my *only* backup, especially if also running btrfs on the backed-up filesystem. Regards, -- 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: What is the vision for btrfs fs repair?
On 2014-10-10 19:43, Bob Marley wrote: On 10/10/2014 16:37, Chris Murphy wrote: The fail safe behavior is to treat the known good tree root as the default tree root, and bypass the bad tree root if it cannot be repaired, so that the volume can be mounted with default mount options (i.e. the ones in fstab). Otherwise it's a filesystem that isn't well suited for general purpose use as rootfs let alone for boot. A filesystem which is suited for general purpose use is a filesystem which honors fsync, and doesn't *ever* auto-roll-back without user intervention. A file system cannot do anything about the *DISKS* not honouring a sync command. That's what the PP was talking about. -- 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: Another defrag question
On 02/21/2013 06:47 PM, Swâmi Petaramesh wrote: Le 21/02/2013 18:25, Hugo Mills a écrit : Correct. But btrfs isn't at that stage yet. It's getting visibly closer, but it's not quite there. Hence the very strong recommendation to keep up with the latest code. Hugo. The matter is that BTRFS had many early adopters just because it is - and has been for long now - in the mainline Linux kernel, so supposed stable and good choice for the future. To be honest (and not wanting to troll, promised) this is the only single reason for which I use BTRFS on 5 of my 6 machines at home - just because I thought that Just upgrade the distro every 6 months and it will become better and better over time, no hassle, make my life easy. Unfortunately many distros don't make it obvious, but Btrfs is still hidden behind a giant EXPERIMENTAL label in the kernel configuration. Regards, -- 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: Another defrag question
On 02/21/2013 10:56 PM, David Sterba wrote: On Thu, Feb 21, 2013 at 09:58:16PM +0100, Bardur Arantsson wrote: On 02/21/2013 06:47 PM, Swâmi Petaramesh wrote: Le 21/02/2013 18:25, Hugo Mills a écrit : Correct. But btrfs isn't at that stage yet. It's getting visibly closer, but it's not quite there. Hence the very strong recommendation to keep up with the latest code. Hugo. The matter is that BTRFS had many early adopters just because it is - and has been for long now - in the mainline Linux kernel, so supposed stable and good choice for the future. To be honest (and not wanting to troll, promised) this is the only single reason for which I use BTRFS on 5 of my 6 machines at home - just because I thought that Just upgrade the distro every 6 months and it will become better and better over time, no hassle, make my life easy. Unfortunately many distros don't make it obvious, but Btrfs is still hidden behind a giant EXPERIMENTAL label in the kernel configuration. Removed in 3.9-rc1 as a part of a broad Kconfig cleanup [--snip--] is it still experimental then? Interesting, but IMO having the experimental label taken off is a necessary, but not sufficient condition for $X to be considered stable :). Regards, -- 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: btrfs across a mix of SSDs HDDs
On 05/01/2012 09:35 PM, Martin wrote:
How well does btrfs perform across a mix of:
1 SSD and 1 HDD for 'raid' 1 mirror for both data and metadata?
Similarly so across 2 SSDs and 2 HDDs (4 devices)?
Can multiple (small) SSDs be 'clustered' as one device and then mirrored
with one large HDD with btrfs directly? (Other than using lvm...)
The idea is to gain the random access speed of the SSDs but have the
HDDs as backup in case the SSDs fail due to wear...
The usage is to support a few hundred Maildirs + imap for users that
often have many thousands of emails in the one folder for their inbox...
(And no, the users cannot be trained to clean out their inboxes or to be
more hierarchically tidy... :-( )
Or is btrfs yet too premature to suffer such use?
From Kconfig:
Btrfs filesystem (EXPERIMENTAL) Unstable disk format
^^
Btrfs is too immature to use in ANY kind of production-like scenario
where you cannot afford to lose a certain amount of data (i.e. be forced
to restore from backup) AND suffer downtime.
I don't think email users are going to be thrilled about the prospect of
lossy email.
(Not that the other questions aren't valid.)
Regards,
--
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: btrfs across a mix of SSDs HDDs
On 05/02/2012 06:28 AM, Fajar A. Nugraha wrote:
On Wed, May 2, 2012 at 9:22 AM, Bardur Arantssons...@scientician.net wrote:
On 05/01/2012 09:35 PM, Martin wrote:
From Kconfig:
Btrfs filesystem (EXPERIMENTAL) Unstable disk format
^^
Btrfs is too immature to use in ANY kind of production-like scenario where
you cannot afford to lose a certain amount of data (i.e. be forced to
restore from backup) AND suffer downtime.
I don't think email users are going to be thrilled about the prospect of
lossy email.
Oracle fully supports btrfs for production environment:
http://oss.oracle.com/ol6/docs/RELEASE-NOTES-UEK2-en.html
http://www.zdnet.com/blog/open-source/oracles-unbreakable-enterprise-kernel-2-arrives-with-linux-30-kernel-btrfs/10588
http://www.oracle.com/us/technologies/linux/index.html
What does fully supports mean? Does it mean that it's actually stable
(considerably more stable that mainline), or does it mean that you can
pay them to help fix a broken FS, for example? Does the included btrfsck
actually work reliably? Is there some non-legalese official statement of
what, exactly, fully supported means and whether OL's btrfs falls
under this rubric?
Also, AFAIUI the 3.0.x kernels (which OL claims to use in the release
notes) are woefully outdated wrt. btrfs reliability/stability. Have all
the more recent stability improvements been backported?
Is the OP using Oracle Linux?
Given the semi-regular posts about FS corruption on this list(*) and the
EXPERIEMENTAL status in the KConfig it would be unwise to use btrfs
for anything called production (unless you can actually afford
downtime/data loss).
(*) I want to make clear that the developers on this list always seem
incredibly responsive and helpful when these posts occur, but it's still
an indication of not-readiness for production. File systems always
take quite a long time to mature, it's just the nature of the beast.
Regards,
--
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
