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.
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...
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.
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!
They probably store the file data in the same part of the inode that is otherwise used for the block list or extent list. So larger files must use that same space to tell the file system where the rest of the data is on the disk, which makes it difficult to also store data in the same location.
Also, putting a small amount of data into the inode would then mean that the rest of the file would no longer be neatly aligned on block boundaries, which makes doing a memmap of the file painful.
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.