Originally posted by startzz
View Post
Announcement
Collapse
No announcement yet.
Tux3 File-System Claims To Be Faster Than Tmpfs
Collapse
X
-
Originally posted by Ericg View Postthat's not an Ubuntu issue, that's a grub issue, and grub2 should be able to boot from every FS the community uses now, including btrfs. tux3 will come once its mainlined
Comment
-
Originally posted by Teho View PostGRUB2 will become quite irrelevant in not so distant future as nearly all machines will ship with UEFI. Then it's better to put the /boot folder under EFI partition and use Gummiboot (or something similar) as loader. This way you can use any file system Linux kernel supports for everything else.All opinions are my own not those of my employer if you know who they are.
Comment
-
Originally posted by Teho View PostGRUB2 will become quite irrelevant in not so distant future as nearly all machines will ship with UEFI. Then it's better to put the /boot folder under EFI partition and use Gummiboot (or something similar) as loader. This way you can use any file system Linux kernel supports for everything else.
Though honestly, if dual-booting, I still use GRUB2. The GRUB shell is always a good thing to have, and GRUB2 doesn't have any problems with being an UEFI program, either.
Comment
-
Originally posted by GreatEmerald View PostIf you really want to get down to that, you should use EFISTUB with efibootmgr directly :PLast edited by Teho; 08 May 2013, 02:45 PM.
Comment
-
Originally posted by Teho View PostGummiboot looks like a better choise to me. It uses EFISTUB and provides simple menu for choosing the kernel. It also support Boot loader Interface which is cool if you use systemd (systemd-analyze shows how much time the firmware and loader took to load and bootctl shows some other information). It also follows the Boot Loader Specification and is ridiculously easy to use; not to mention it automatically detects Windows and OS X installs.
Comment
-
Originally posted by ssam View PostThat's a good way to look at it. basically this has uncovered a bottle neck in tmpfs.
tmpfs should always be fastest because there are lots of things that it does not need to worry about (eg unexpected shutdown safety). but there are probably bits in it that are slower then they could be, and nobody notices until they try to benchmark against a competing implementation.
If that does not fill your mind with rage and your heart with fear I don't know what. fsync() must not return before the data is on the media. tux3 returns fsync() before the data is on the media.
Basically: cheating. Read the emails yourself.
Next time moronix posts some crap, check it for yourself. Especially with filesystems. Saying that moronix track record is spotty in that regard is an understatement.
Comment
-
Originally posted by energyman View Postthey uncovered NOTHING. They changed dbench and BROKE FSYNC.
If that does not fill your mind with rage and your heart with fear I don't know what. fsync() must not return before the data is on the media. tux3 returns fsync() before the data is on the media.
Basically: cheating. Read the emails yourself.
Comment
-
I own you nothing. Benchmarking with a broken fsync() and then claim to be faster is deceptive at best.
It is like saying that a fused automatic fuse is much better because it can tolerate a much higher current.
T'so and Chinner said it much better than I can.
Comment
Comment