Slashdot Mirror
Linux 3.8 Released
diegocg writes "Linux kernel 3.8 has been released. This release includes support in Ext4 for embedding very small files in the inode, which greatly improves the performance for these files and saves some disk space. There is also a new Btrfs feature that allows for quick disk replacement, a new filesystem F2FS optimized for SSDs; support for filesystem mount, UTS, IPC, PID, and network namespaces for unprivileged users; accounting of kernel memory in the memory resource controller; journal checksums in XFS; an improved NUMA policy redesign; and, of course, the removal of support for 386 processors. Many small features and new drivers and fixes are also available. Here's the full list of changes."
First post running Linux 3.8 Kernel!
I thought we were on 2.6 for eternity. Where did 3.8 come from all of a sudden?
Intel's latest generation of desktop i5/i7 CPUs appear to be buggy. People I know working in CFD are finding all sorts of quirks so have gone back to older and slower Xeons. Nothing for the desktop series is documented for bugs as far as I'm aware, I don't think Intel test them as much in design as workstation grade CPUs, and published bugs for Xeons you're not allowed to talk about them.
Specifically the actual i386 family is no longer supported. The i486 family, including the 486SX (which doesn't even have floating point) are still technically supported by the Linux kernel, you just won't find very much software to run on them. So we're not just talking "before the Pentium" but further back in history. There are i486 PCs dating back to 1989, think Dead Poets Society. So Linux still runs on hardware that's older than Linux, just not hardware that was already /cheap/ when Linux began.
ext4 has been altered with added functionalities - I will wait some time before applying the upgrade, just to be sure ext4 is stable again...
Slashdot, fix the reply notifications... You won't get away with it...
...Does it run linux?
rm -rf --no-preserve-root /
Intel's latest generation of desktop i5/i7 CPUs appear to be buggy. People I know working in CFD are finding all sorts of quirks so have gone back to older and slower Xeons.
One difference is that the intel desktop CPUs generally don't have ECC whereas the Xeon ones do.
Do the new i7s produce consistent results each time? If so, then lack ECC isn't the problem.
There could also be some subtle difference in IEEE modes.
You could try dumping everything from every stage of the algorithm out and seeing when two runs start to differ.
SJW n. One who posts facts.
Isn't it normal for any processor to have errata? There are currently 95 bugs listed for Ivy Bridge on Intel's site. There are 120 for Sandy Bridge.
From TFA it seems that large files won't benefit from the change in ext4. This seems an odd strategy.
Wouldn't it have made more sense to put the first part of the file data into the inode regardless of the size of the file ? That way every file would get an initial access speed boost by omitting seek latency, and large inodes would get used very effectively..
Links?
OpenBSD still supports '386 processors
Karma: Excellent. 15 moderator points expire sometime.
If you are looking to avoid all errata, then buy an abacus. All CPUs have bugs.
Tequila: It's not just for breakfast anymore!
but if you don't want to pick a vendor-supported one, then at least pick one of the "long-term-support" kernels. These are ones that the kernel developers have committed to backporting fixes to for longer than usual. The most recent "long-term-support" kernel is 3.4 (will be supported for at least 2 yrs), the previous (and still-supported) one was 3.0.
In the case of an bug introduced in 3.0.x, definitely that should be reported. Normally that sort of thing doesn't happen in stable kernels.
"... the removal of support for 386 processors..."
Wow, that's a lot of CPUs to deprecate in one release. Does anyone have a list of the three hundred and eight-six processors that are no longer supported? ;-)
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
No, F2FS is not meant for bare NAND and doesn't do wear-levelling. It is meant for cheap flash media such as USB flash drives, SD cards, eMMC and such. Those devices have controllers that perform wear-levelling and other flash-translation layer functions. They present as block devices just like SSDs and regular hard drives. Conventional filesystems such as ext4 are optimized for spinning-rust and have to manage things like the fact that random access takes a significant amount of time while it has to wait for the next sector to come underneath the read/write head. With flash media, the seek time is zero but erasing a block takes a long time. There are of course many other differences. F2FS is designed to exploit the advantages of flash media and cope with the disadvantages. That said, I don't think I'd want to run F2FS on an SSD. SSDs have sophisticated controllers that try to compensate for the advantages and disadvantages of flash media with respect to conventional filesystems. I think you'd wind up with F2FS fighting it out with the SSD controller and I think perform would suffer as a consequence.
It is unfortunate that the Linux kernel still does not support a number of key features available in currently available hardware. Such as some features that Windows8 supports out-of-the box. Here's one example: AMD's LWP feature set. It requires XSAVE/XRSTOR, but has been rejected by the Linux kernel developers. No, I'm NOT an AMD employee. Yes I do own a couple of desktops based upon AMD cpus. Motivation: COST, COST, COST.