Try a BSOD at depth
|
| Author | Content |
|---|---|
| Ridcully Jun 29, 2015 8:10 AM EDT |
It terrifies me. I'm a retired naval officer. Although I am not an ex-submariner, I've been out in a submarine and I am very aware of the rigours of the "undersea service". . Just the thought of a BSOD while submerged makes me cringe in fear - it is almost a death sentence. If this article is correct, and WinXP is STILL the principal OS on US ships then it is irresponsible in the extreme on the part of US Naval command. Or that's how I would see it. Of course, I could be utterly wrong, because I was never in the US navy....nevertheless, the thought of this situation as I have painted it, is a horror. |
| penguinist Jun 29, 2015 9:15 AM EDT |
Looks like the Brits were also going down that path. Hopefully this is just "old news" in their case. http://www.cnet.com/news/royal-navy-goes-with-windows-for-su... |
| JaseP Jun 29, 2015 9:44 AM EDT |
I think it was the USS Yorktown that had to be towed back to port several times because of Windows NT failures... |
| gus3 Jun 29, 2015 2:11 PM EDT |
*clears throat* I crashed a Linux filesystem(*) last Friday evening, and the only way to reboot was using the Raising Skinny Elephants sequence. The panic reported an illegal zero-page access. Very uncool. (*)testing btrfs using 30 threads in dbench. |
| penguinist Jun 29, 2015 2:27 PM EDT |
gus3: I've never experienced such an issue, then again, I've not ventured too far from ext4 or predecessors. I hope you wrote up a detailed bugzilla report, such issues are usually fixed pretty fast if they can be reproduced and/or be well documented. |
| JaseP Jun 29, 2015 4:50 PM EDT |
Quoting:(*)testing btrfs using 30 threads in dbench.Therein lies the problem,... no?!?! I'm sorry to say it, but btrfs is still too new to be using in a production environment. If you read the Wiki, you'll get that message pretty much by reading,... "Due to the fast development speed, the state of development of the filesystem improves noticeably with every new Linux version, so it's recommended to run the most modern kernel possible." and,... "For benchmarks, it's recommended to test the latest stable Linux version, and not any older." See; https://btrfs.wiki.kernel.org/index.php/Main_Page Linux stability in the well established, stable branches is not an issue. Running the Latest/Greatest can be. |
| BernardSwiss Jun 29, 2015 7:53 PM EDT |
So, would it be fair to say that btrfs is plenty good enough for desktop system use, but not yet ready for servers or the data center? |
| gus3 Jun 30, 2015 2:08 PM EDT |
Okay, here's the story, soon to be a (long-overdue) article. I've done filesystem comparisons in the past, focusing on CPU speed and disk elevator (I/O scheduler) interactions. Three years ago, I noticed that btrfs seemed to scale very nicely under load, so I ran a test to find saturation points of the various FS's. They all saturated before 10 threads, except btrfs, which saturated around 70 threads and then degraded in a very noisy fashion. Fast-forward: I ran the tests the day before the 4.1 kernel was released, so those results have been tossed anyway. But the executive summary would have been: ext4 is the big winner if you're not worried about the bug from a couple weeks ago. Under light load, JFS has held its own; under heavy load, btrfs pulls ahead of JFS. XFS used to be a big winner, but is now a shadow of its former self. And btrfs saturated around 30 threads. I would have started the write-up today, but the 4.1.1 patch just came out. However, no code in the disk I/O stack was affected, so the results are probably still valid. As for the btrfs crash, the system was very "dirty" after having run dbench over 150 times with no reboot. There's no telling what crazy interactions may have left a leak here or there. After the reboot and necessary fsck, I re-ran the scaling test with no problem. (tl;dr reproducibility is questionable at best.) |
| notbob Jul 01, 2015 10:55 AM EDT |
> So, would it be fair to say that btrfs is plenty good enough for desktop system use.... I would say, wait and see. I recall when reiserfs was all the rage, so I used it on my Slackware desktop box. Then I started noticing data missing on this lightly trafficked/loaded machine. I mentioned it on alt.os.linux.slackware and others concurred. I changed to ext3/4 and never had another problem. |
| linux4567 Jul 23, 2015 1:27 AM EDT |
I have been using JFS for large data filesystems (4-8 Terabytes) for more than 5 years now (at home) and it has been flawless so far. It has always survived any abrupt power off (power outages and other reasons) without ever corrupting itself or the data stored on it.
So I swear by JFS. I only use ext4 for the system partitions these days. |
| kikinovak Jul 23, 2015 2:45 AM EDT |
ext2/3/4 for the last 14 years. Never a single problem. |
| BernardSwiss Jul 23, 2015 3:08 AM EDT |
" ext2/3/4 for the last 14 years. Never a single problem. " Ditto. And I don't have a UPS to ease me through the occasional power interruptions, either. (Just one more area in which Linux has proved itself to be more robust than Windows (though I hear Win 7 and up may be pretty solid that way)). |
| seatex Jul 23, 2015 9:20 AM EDT |
EXT 3 and now EXT 4 on all my machines. I don't even try anything else. |
| gus3 Jul 23, 2015 4:56 PM EDT |
Ext4's defrag cost me some data last year. The files' lengths were correct, but the blocks were all zeros. Fortunately, the affected files were all in the root partition, mostly under /usr, so just re-installing all the packages fixed it. XFS no longer relies on heavy caching, given that PC's don't have giant capacitors in them to hold power long enough to flush cache on power failure. OTOH, JFS follows IBM's philosophy of "do it right before doing it fast." A wrong answer is useless at best, no matter how fast you get it. It hit me like a thunderbolt: What's 2+2? Zero. What's the capital of France? Zero. How many fingers do I have? Zero. 'Nuff said. (My nephew outsmarted everyone on that last one. His answer: "All of them.") |
| penguinist Jul 23, 2015 5:31 PM EDT |
gus3: I'm curious which defrag program you were using that corrupted an ext4 file system. I've never ever seen a problem with ext4, then again, I've also never attempted a defrag. |
| gus3 Jul 23, 2015 5:36 PM EDT |
"e4defrag". |
| bob Jul 23, 2015 5:44 PM EDT |
Looking in the Fedora/CentOS/Epel repositories I see: "No package e4defrag available." and my favorite search engine leads me to some reports of this program being "buggy". Looks like e4defrag didn't make it through the Fedora/CentOS/RedHat QA filter. I think I'll point the finger at the defrag app in this case and my high opinion of the robustness of ext4 can stay intact. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!