XFS Updates Queued For Linux 4.13

[flubba86]

Well, there's always the route with formal methods and very strongly typed languages. Guess what - industry rarely cares about them.

Thats a new and innovative way of saying "You should rewrite it in Rust"

[puleglot]

I don't recommend XFS for desktop Linux users. Some games (eg. Football Manager 2014) and programs doesn't work there and there is no support for shrinking.

Doesn't work on any XFS filesystem or doesn't work on a large XFS filesystem with 64-bit inodes?

[caligula]

Thats a new and innovative way of saying "You should rewrite it in Rust"

Nope. Even SML would work better than C. The SML specification is over 25 years old.

[Zucca]

Something that bothers me is how 'all' the file systems are constantly getting bugfixes, even after some being around for decades and yet, during all this time, we blindly entrust our data to them as if they were completely bug free... Is it just me that worries about these things?...

Old filesystems do need patches from time to time.
I've lost data two times when I've used XFS over mdraid. At that time there were some bug that caused the whole raid stack corruption if XFS was used. I do not know if it's fixed yet but I'm not interested of it anymore, I've switched to btrfs years ago. On a single disk XFS has worked flawlessly.

Whatever the case may be - if you have valuable data, keep backups.

[nomadewolf]

It both worries and annoys me as well, but fortunately with most of the filesystems (i.e. filesystems that aren't BTRFS), the bugs seem to be rather minor and hard to reproduce. I've never encountered any major bug in XFS, meanwhile I've used BTRFS and had it cause major problems that were a pain to recover from when my system would freeze (experimenting with KVM mostly) or the power would go out.

But yes... definitely keep backups is what it comes down to.

Thanks.
But carefull with bashing btrfs... even though it's full of bugs you aren't allowed to say it. Oh, crap, here we go again...

[nomadewolf]

That's just one of the less important reasons to have backups (hardware failures and human errors being far more important reasons to have backups).

I'm not worried. I have backups.

Sudden realization:
If i buy 2 similar drives, one for use and the other for backup, i shouldn't use the same file system on both...

[pal666]

during all this time, we blindly entrust our data to them

maybe you should stop doing that

[pal666]

Well, there's always the route with formal methods and very strongly typed languages. Guess what - industry rarely cares about them.

guess what - most bugs can't be fixed by that route. there is no known way to make bugfree software

[pal666]

If i buy 2 similar drives, one for use and the other for backup, i shouldn't use the same file system on both...

regardless of drive similarity

[caligula]

guess what - most bugs can't be fixed by that route. there is no known way to make bugfree software

Stop trolling.

1) I never claimed that formal methods and better languages produce bug free code. I only told it's a solution towards that direction.

2) The fact is, statistically speaking there's around X bugs per Y lines of code. Some say it's 1 bug per 1000 LOC in projects with focus on code correctness and much much more in real world projects. This metric already tells there are at least 23 000 bugs in kernel 4.12. My guess is, there could be millions on bugs since the domain is quite demanding and many drivers are written without the help of official documentation or by non-experts.

3) So, the number of bugs is quite high. It's not like we're aiming at 0 bugs/whole kernel. If there are 10 million bugs, 9 million is a lot less. People perceive program as buggy when the bug density is relatively high such as in btrfs code. You're erroneously thinking that the goal is 0. It's much higher. Besides, many bugs are not code level but design level bugs - a count of 0 bugs seems unimplementable when the requirements change all the time.

4) Bugs can be split into categories. Some categories of bugs don't appear in better languages because the definition of better here is that the languages only differ from C by prohibiting these types of bugs. For instance, built-in tagged unions prohibit problematic use cases which C allows with the struct + union hack. Thus it's quite easy to calculate how many bugs will be eliminated with the new language if the bugs were enumerated.