similar to: Btrfs going forward, was: Errors on an SSD drive

To be honest, I'd not try a btrfs volume on a notebook SSD. I did that on a couple of systems and it corrupted pretty quickly. I'd stick with xfs/ext4 if you manage to get the drive working again. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com

Warren Young wrote: > [...] >>> What do they suggest as a replacement? > > Stratis: https://stratis-storage.github.io/StratisSoftwareDesign.pdf Can I use that now? > The main downside to Stratis I see is that it looks like 1.0 is scheduled to coincide with RHEL 8, based on the release dates of RHELs past, which means it won?t have any kind of redundant storage options to

I hate top posting, but since you've got two items I want to comment on, I'll suck it up for now. Having SSDs alone will give you great performance regardless of filesystem.? BTRFS isn't going to impact I/O any more significantly than, say, XFS.? It does have serious stability/data integrity issues that XFS doesn't have.? There's no reason not to use SSDs for storage of

Hi, is there anything that speaks against putting a cyrus mail spool onto a btrfs subvolume?

Mark Haney wrote: > On 09/07/2017 01:57 PM, hw wrote: >> >> Hi, >> >> is there anything that speaks against putting a cyrus mail spool onto a >> btrfs subvolume? >> > I might be the lone voice on this, but I refuse to use btrfs for anything, much less a mail spool. I used it in production on DB and Web servers and fought corruption issues and scrubs

On 09/08/2017 09:49 AM, hw wrote: > Mark Haney wrote: >> I hate top posting, but since you've got two items I want to comment >> on, I'll suck it up for now. > > I do, too, yet sometimes it?s reasonable.? I also hate it when the lines > are too long :) > I'm afraid you'll have to live with it a bit longer.? Sorry. >> Having SSDs alone will give you

Chris Murphy wrote: > Changing the subject since this is rather Btrfs specific now. > > > > On Fri, Aug 11, 2017 at 5:41 AM, hw <hw at gc-24.de> wrote: >> Chris Murphy wrote: >>> >>> On Wed, Aug 9, 2017, 11:55 AM Mark Haney <mark.haney at neonova.net> wrote: >>> >>>> To be honest, I'd not try a btrfs volume on a notebook

I think it depends on who you ask. Facebook and Netflix are using it extensively in production: https://www.linux.com/news/learn/intro-to-linux/how-facebook-uses-linux-and-btrfs-interview-chris-mason Though they have the in-house kernel engineering resources to troubleshoot problems. When I see quotes like this [1] on the product's WIKI: "The parity RAID code has multiple serious

On 09/08/2017 01:31 PM, hw wrote: > Mark Haney wrote: > > I/O is not heavy in that sense, that?s why I said that?s not the > application. > There is I/O which, as tests have shown, benefits greatly from low > latency, which > is where the idea to use SSDs for the relevant data has arisen from.? > This I/O > only involves a small amount of data and is not sustained

I am building a new system using an Kingston 240GB SSD drive I pulled from my notebook (when I had to upgrade to a 500GB SSD drive). Centos install went fine and ran for a couple days then got errors on the console. Here is an example: [168176.995064] sd 0:0:0:0: [sda] tag#14 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK [168177.004050] sd 0:0:0:0: [sda] tag#14 CDB: Read(10)

Mark Haney wrote: > On Fri, Aug 11, 2017 at 1:00 PM, Chris Murphy <lists at colorremedies.com> > wrote: > >> Changing the subject since this is rather Btrfs specific now. >> >> >> >>>> >>>> Sounds like a hardware problem. Btrfs is explicitly optimized for SSD, >> the >>>> maintainers worked for FusionIO for several

hw wrote: > Mark Haney wrote: <snip> >> BTRFS isn't going to impact I/O any more significantly than, say, XFS. > > But mdadm does, the impact is severe. I know there are ppl saying > otherwise, but I?ve seen the impact myself, and I definitely don?t want > it on that particular server because it would likely interfere with > other services. <snip> I

Warren Young wrote: > On May 17, 2019, at 9:53 AM, John Hodrien <J.H.Hodrien at leeds.ac.uk> > wrote: >> On Fri, 17 May 2019, James Szinger wrote: >>> On Fri, May 17, 2019 at 3:17 AM John Hodrien >>> <J.H.Hodrien at leeds.ac.uk> wrote: >>> >>>> RHEL advice would clearly be not to use btrfs. >>> >>> I'm curious, is

On Fri, September 8, 2017 9:48 am, hw wrote: > m.roth at 5-cent.us wrote: >> hw wrote: >>> Mark Haney wrote: >> <snip> >>>> BTRFS isn't going to impact I/O any more significantly than, say, XFS. >>> >>> But mdadm does, the impact is severe. I know there are ppl saying >>> otherwise, but I??ve seen the impact myself, and I

On Aug 11, 2017, at 11:00 AM, Chris Murphy <lists at colorremedies.com> wrote: > > On Fri, Aug 11, 2017 at 5:41 AM, hw <hw at gc-24.de> wrote: >> That?s one thing I?ve been wondering about: When using btrfs RAID, do you >> need to somehow monitor the disks to see if one has failed? > > Yes. > > The block layer has no faulty device handling That is one

On Fri, 17 May 2019, James Szinger wrote: > On Fri, May 17, 2019 at 3:17 AM John Hodrien <J.H.Hodrien at leeds.ac.uk> wrote: >> RHEL advice would clearly be not to use btrfs. > > I'm curious, is there anything in RHEL 8 that would replace BTRFS or > ZFS? I'm experimenting with BTRFS on one system and the snapshot and > subvolume features are nice. I assume

Hi, After reading through the btrfs documentation I''m curious to know if it''s possible to ever securely erase a file from a btrfs filesystem (or ZFS for that matter). On non-COW filesystems atop regular HDDs one can simply overwrite the file with zeros or random data using dd or some other tool and rest assured that the blocks which contained the sensitive information have

On Fri, Aug 11, 2017 at 11:17 AM, Mark Haney <mark.haney at neonova.net> wrote: > On Fri, Aug 11, 2017 at 1:00 PM, Chris Murphy <lists at colorremedies.com> > wrote: > >> Changing the subject since this is rather Btrfs specific now. >> >> >> >> >> >> >> Sounds like a hardware problem. Btrfs is explicitly optimized for SSD,

On Mon, Feb 8, 2016 at 3:18 PM, <m.roth at 5-cent.us> wrote: > Chris Murphy wrote: >> DBAN is obsolete. NIST 800-88 for some time now says to use secure erase >> or enhanced security erase or crypto erase if supported. >> >> Other options do not erase data in remapped sectors. > > dban doesn't? What F/OSS does "secure erase"? And does it do

hw wrote: > Mark Haney wrote: >> On 09/08/2017 09:49 AM, hw wrote: >>> Mark Haney wrote: <snip> > Probably with the very expensive SSDs suited for this ... <snip> >>> >>> That?s because I do not store data on a single disk, without >>> redundancy, and the SSDs I have are not suitable for hardware RAID. <snip> That's a biggie: