241–250 of 260 posts
Earlier quoted context omitted.
Yes, the only real problems are edge cases. I use it all the time.
What are the equivalent edge cases in XFS, ZFS, ext4, Reiser4, Reiser5, bcachefs, or f2fs that make btrfs worth considering on a level playing field?
Earlier quoted context omitted.
> The logical successor was supposed to be btrfs, but that project IMHO may never be ready for production use. https://btrfs.wiki.kernel.org/index.php/Production_Users Facebook deployed it on millions of servers. Is that production enough? Synology NAS devices also use it.
Lots of people seem to turn up their nose at btrfs. Is there a reason for that? Was it perhaps launched before it was really ready and people still remember early versions?
Earlier quoted context omitted.
A filesystem is a database.
But a special kind of database, that is usually bad with a lot of small entries, especially if they don't have a hierarchy (many files in one folder). Most SQL or NoSQL databases are much better at organizing small "files".
Earlier quoted context omitted.
Edge cases like Raid5/6 which had the write hole issue approximately a decade after btrfs was released. At some point you say "This filesystem has lost so much of my data that I will never return to it."
That's pretty old news. It's been problem free for a long time and it's very well documented where you might have issues.
Earlier quoted context omitted.
I feel like there's a small tautology here- who is most likely to name the software package after themselves? A narcissist, of course, and narcissism is a component of sociopathy.
So you also think Linus Torvalds is a narcissist ? And every people who name their project or company after their names are potential sociopaths ? What about all scientists who gave their names to the effects or law of physics (or math formulas) they discovered... ?
Scientists also generally don't name their discoveries after themselves. The honor of getting someone named after yourself is something that your colleagues are supposed to bestow in recognition of achievements - sometimes long after the person in question is long dead.
Earlier quoted context omitted.
Not really, no. But you'd have to get the source and build the kernel module for the specific kernel it runs on. There are mechanisms to do this, such as DKMS (e.g. Virtualbox does this: it provides its kernel modules' code, OS/user provides kernel source, magic happens and sometimes it even works on the first try); having the module code always present in kernel source (even if it doesn't get built) is more convenie…
That's what I thought; I run zfs-dkms on my server, and I just assumed that other filesystems could do the same.
Earlier quoted context omitted.
It's always been. I used it on my servers in "Raid 10" mode and on my daily driver for 3 years now. As long as you don't do BTRFS-level raid 5/6. (Just do lvm-level or md-raid-level raid 5/6) don't do many subvolume with quota. (many subvolumes is fine) It's production ready. I don't know where this "btrfs is not stable" coming from. According to HackerNews, I should have lost my data due to BTRFS 10 times already.
It never ceases to amaze me how so many people only consider their own experiences as relevant "btrfs is not stable" is coming from people for whom btrfs has not been stable. Why is that so hard to understand?
"The Btrfs code base is stable"
And https://btrfs.wiki.kernel.org/index.php/Status is exactly what I said in the GP. Besides quotas and RAID56, everything is stable.
Earlier quoted context omitted.
Yes.. but you couldn't grow ZFS. I don't understand what your point is.
Unless Im'm terribly mistaken one could always grow ZFS, but it was via adding more pools.
Earlier quoted context omitted.
That's pretty old news. It's been problem free for a long time and it's very well documented where you might have issues.
Burn me once, shame on you, burn me twice, shame on me. If you purchased a new ford and that car fell apart a week later, would you ever buy a ford again? Some will, most wont.
Earlier quoted context omitted.
Try the web server Redbean. You put it all in a single zip file, serving a file simply copies the pre-gzipped content directly into a tcp stream. Obviously some of the FS read performance cost is moved into navigating the zip file, but the storage overhead is not, and nor is the read+write-able nature of the FS.
Do zip files really offer performant random access with tens of millions of entries?