Language Selection

English French German Italian Portuguese Spanish

Reiser

Reiser4/Reiser5 Updated For Linux 5.8

Filed under
Reiser

Edward Shishkin continues pushing ahead with not only maintaining the existing out-of-tree Reiser4 file-system code but also developing Reiser5 seemingly without any major corporate support. Reiser4 and the experimental Reiser5 file-system code were updated on Monday for Linux 5.8 kernel compatibility.

The Reiser4 kernel driver along with the unstable Reiser5 kernel code saw new patch releases for supporting them on the Linux 5.8 stable kernel (Linux 5.8.1 target to be exact).

Read more

Reiser4/Reiser5 Updated For Linux 5.7 Kernel Compatibility

Filed under
Reiser

It was just over a week ago that Reiser4 was updated for Linux 5.6 support while now it's been updated for the newly-minted Linux 5.7 stable kernel along with updating the experimental Reiser5 file-system for this latest kernel series.

Uploaded today by Edward Shishkin was Reiser4 for Linux 5.7.1. Though given the minimal changes with 5.7.1 compared to last week's 5.7 release, the patch presumably should apply cleanly there as well. There are no reports of any other functional Reiser4 changes besides re-basing to the new kernel series.

Read more

Reiser5 Updates For Linux 5.5 Along With Reiser4

Filed under
Reiser

The out-of-tree Reiser4 and Reiser5 (Reiser4 v5) patches have been updated against the recently stabilized Linux 5.5 kernel.

Main Reiser4 developer Edward Shishkin re-based the Reiser4 file-system patch against Linux 5.5.1 along with the experimental Reiser5.

At the end of 2019 is when Shishkin announced Reiser5 file-system development with introducing the concepts of local volumes capable of parallel scaling out and other key iterations over the current Reiser4 design.

Read more

Reiser4 File-System Is Still Ticking In 2019 - Now Updated For Linux 5.3 Compatibility

Filed under
Linux
Reiser

Edward Shishkin continues near single-handedly maintaining the out-of-tree Reiser4 code that at this point still has no apparent trajectory towards mainline. The former Namesys developer previously indicated it's unlikely to see Reiser4 merged unless there is a company backing it to get it through the review process for merging into mainline. While Reiser4 was quite promising for its early time, it's only getting more difficult with Reiser4 effectively stagnating for years now while SUSE/openSUSE continues backing Btrfs, Ubuntu increasingly investing in ZFS support, Red Hat developing Stratis, XFS continuing to be advanced by Red Hat and others as well, Google continuing to invest in the likes of EXT4/F2FS, and there also being Bcachefs and other open-source storage solutions that are more promising than Reiser4 in 2019. Nevertheless, the out-of-tree kernel patches continue to be updated.

Read more

Reiser4 Brought To The Linux 5.0 Kernel

Filed under
Reiser

For those still using the out-of-tree Reiser4 file-system, it may be about time to consider alternatives like Btrfs, XFS, ZFS On Linux, F2FS, or even the likes of Stratis and Bcachefs. But should you still be using this once promising file-system, the out-of-tree patches have been revised to now work with the Linux 5.0 kernel.

There still is no trajectory for Reiser4 to the mainline Linux kernel with no major companies or other stakeholders backing Reiser4 but just a small group of developers and enthusiasts left working on this successor to ReiserFS. With the latest code posted on Friday by former Namesys developer Edward Shishkin, the Reiser4 kernel driver has been re-based to the Linux 5.0 kernel but with no other changes to the file-system noted.

Read more

Reiser4 File-System Benchmarks With Linux 4.17

Filed under
Graphics/Benchmarks
Linux
Reiser

It's been about three years since last carrying out any file-system performance benchmarks of Reiser4, but being curious how it stacks up against the current state of today's mainline Linux file-systems, here are some fresh performance tests of Reiser4 using the Linux 4.17 kernel. The Reiser4 performance was compared to Reiserfs, EXT4, Btrfs, XFS, and F2FS.

Read more

Reiser4 Updated For Linux 4.14 & Introduces Zstd Compression Support

Filed under
Reiser

The out-of-tree Reiser4 file-system driver has been updated with compatibility for the latest Linux 4.14 stable series. Besides reworking the code to run on Linux 4.14, this controversial file-system has also added support for Zstd file-system compression.

Linux 4.14 introduced Zstd support in the mainline kernel and wired it in for SquashFS and Btrfs. Our Btrfs Zstd benchmarks have been promising for transparent file-system compression compared to the other supported algorithms. Reiser4 has now picked up Zstd compression as an eventual replacement to their Gzip compression support.

Read more

Reiser4 Is Now Ready For Linux 4.13

Filed under
Reiser

For those wanting to use the Reiser4 file-system with the just-released Linux 4.13 kernel, patches are already available.

Less than one week after the release of the Linux 4.13 stable kernel, Edward Shishkin has already released an updated patch for the out-of-tree Reiser4 file-system for working with this new stable series.

Read more

Reiser4 Updated For Linux 4.12, Experimental Data Striping Support

Filed under
Reiser

Those using the Reiser4 file-system in some capacity can now safely upgrade to the Linux 4.12 kernel.

Edward Shishkin has updated this out-of-tree file-system for the Linux 4.12 kernel so it can be built with the latest mainline stable release.

Read more

Reiser4 Updated For The Linux 4.10 Kernel

Filed under
Reiser

The out-of-tree Reiser4 file-system has been updated for the Linux 4.10 kernel.

Reiser4 for the Linux 4.10.0 kernel is available as of earlier this week, managing to release their updated file-system driver code quite promptly. This port to Linux 4.10 yielded a few changes to the Reiser4 code as they re-based to this Linux kernel with the ->readlink() of inode operations being removed as well as the WRITE_FLUSH_FUA flag being removed.

Read more

Syndicate content

More in Tux Machines

How to Contribute to the Fight Against COVID-19 With Your Linux System

Want to contribute to the research on coronavirus? You don’t necessarily have to be a scientist for this. You may contribute with part of your computer’s computing power thanks to Rosetta@home project. Read more

Raspberry Pi 4 as Desktop Computer: Is It Really Viable?

There’s little doubt that the Raspberry Pi 4 is significantly more powerful than its predecessors. Its based on the faster ARM Cortex-A72 microarchitecture and has four cores pegged at marginally-higher clock speeds. The graphics subsystem is significantly beefed up as well, running at twice the maximum stock clocks as the outgoing model. Everything about it makes it a viable desktop replacement. But is it really good enough to replace your trusty old desktop? I spent three weeks with the 8GB version of the Pi 4 to answer that million-dollar question. Read more

10 Linux Distributions and Their Targeted Users

As a free and open-source operating system, Linux has spawned several distributions over time, spreading its wings to encompass a large community of users. From desktop/home users to Enterprise environments, Linux has ensured that each category has something to be happy about. [...] Debian is renowned for being a mother to popular Linux distributions such as Deepin, Ubuntu, and Mint which have provided solid performance, stability, and unparalleled user experience. The latest stable release is Debian 10.5, an update of Debian 10 colloquially known as Debian Buster. Note that Debian 10.5 does not constitute a new version of Debian Buster and is only an update of Buster with the latest updates and added software applications. Also included are security fixes that address pre-existing security issues. If you have your Buster system, there’s no need to discard it. Simply perform a system upgrade using the APT package manager. The Debian project provides over 59,000 software packages and supports a wide range of PCs with each release encompassing a broader array of system architectures. It strives to strike a balance between cutting edge technology and stability. Debian provides 3 salient development branches: Stable, Testing, and Unstable. The stable version, as the name suggests is rock-solid, enjoys full security support but unfortunately, does not ship with the very latest software applications. Nevertheless, It is ideal for production servers owing to its stability and reliability and also makes the cut for relatively conservative desktop users who don’t really mind having the very latest software packages. Debian Stable is what you would usually install on your system. Debian Testing is a rolling release and provides the latest software versions that are yet to be accepted into the stable release. It is a development phase of the next stable Debian release. It’s usually fraught with instability issues and might easily break. Also, it doesn’t get its security patches in a timely fashion. The latest Debian Testing release is Bullseye. The unstable distro is the active development phase of Debian. It is an experimental distro and acts as a perfect platform for developers who are actively making contributions to the code until it transitions to the ‘Testing’ stage. Overall, Debian is used by millions of users owing to its package-rich repository and the stability it provides especially in production environments. Read more

LWN on Linux and Linux Foundation Bits

  • Modernizing the tasklet API

    Tasklets offer a deferred-execution method in the Linux kernel; they have been available since the 2.3 development series. They allow interrupt handlers to schedule further work to be executed as soon as possible after the handler itself. The tasklet API has its shortcomings, but it has stayed in place while other deferred-execution methods, including workqueues, have been introduced. Recently, Kees Cook posted a security-inspired patch set (also including work from Romain Perier) to improve the tasklet API. This change is uncontroversial, but it provoked a discussion that might lead to the removal of the tasklet API in the (not so distant) future. The need for tasklets and other deferred execution mechanisms comes from the way the kernel handles interrupts. An interrupt is (usually) caused by some hardware event; when it happens, the execution of the current task is suspended and the interrupt handler takes the CPU. Before the introduction of threaded interrupts, the interrupt handler had to perform the minimum necessary operations (like accessing the hardware registers to silence the interrupt) and then call an appropriate deferred-work mechanism to take care of just about everything else that needed to be done. Threaded interrupts, yet another import from the realtime preemption work, move the handler to a kernel thread that is scheduled in the usual way; this feature was merged for the 2.6.30 kernel, by which time tasklets were well established. An interrupt handler will schedule a tasklet when there is some work to be done at a later time. The kernel then runs the tasklet when possible, typically when the interrupt handler finishes, or the task returns to the user space. The tasklet callback runs in atomic context, inside a software interrupt, meaning that it cannot sleep or access user-space data, so not all work can be done in a tasklet handler. Also, the kernel only allows one instance of any given tasklet to be running at any given time; multiple different tasklet callbacks can run in parallel. Those limitations of tasklets are not present in more recent deferred work mechanisms like workqueues. But still, the current kernel contains more than a hundred users of tasklets. Cook's patch set changes the parameter type for the tasklet's callback. In current kernels, they take an unsigned long value that is specified when the tasklet is initialized. This is different from other kernel mechanisms with callbacks; the preferred way in current kernels is to use a pointer to a type-specific structure. The change Cook proposes goes in that direction by passing the tasklet context (struct tasklet_struct) to the callback. The goal behind this work is to avoid a number of problems, including a need to cast from the unsigned int to a different type (without proper type checking) in the callback. The change allows the removal of the (now) redundant data field from the tasklet structure. Finally, this change mitigates the possible buffer overflow attacks that could overwrite the callback pointer and the data field. This is likely one of the primary objectives, as the work was first posted (in 2019) on the kernel-hardening mailing list.

  • Android kernel notes from LPC 2020

    Todd Kjos started things off by introducing the Android Generic Kernel Image (GKI) effort, which is aimed at reducing Android's kernel-fragmentation problem in general. It is the next step for the Android Common Kernel, which is based on the mainline long-term support (LTS) releases with a number of patches added on top. These patches vary from Android-specific, out-of-tree features to fixes cherry-picked from mainline releases. The end result is that the Android Common Kernel diverges somewhat from the LTS releases on which it is based. From there, things get worse. Vendors pick up this kernel and apply their own changes — often significant, core-kernel changes — to create a vendor kernel. The original-equipment manufacturers begin with that kernel when creating a device based on the vendor's chips, but then add changes of their own to create the OEM kernel that is shipped with a device to the consumer. The end result of all this patching is that every device has its own kernel, meaning that there are thousands of different "Android" kernels in use. There are a lot of costs to this arrangement, Kjos said. Fragmentation makes it harder to ensure that all devices are running current kernels — or even that they get security updates. New platform releases require a new kernel, which raises the cost of upgrading an existing device to a new Android version. Fixes applied by vendors and OEMs often do not make it back into the mainline, making things worse for everybody. The Android developers would like to fix this fragmentation problem; the path toward that goal involves providing a single generic kernel in binary form (the GKI) that all devices would use. Any vendor-specific or device-specific code that is not in the mainline kernel will need to be shipped in the form of kernel modules to be loaded into the GKI. That means that Android is explicitly encouraging vendor modules, Kjos said; the result is a cleaner kernel without the sorts of core-kernel modifications that ship on many devices now. This policy has already resulted in more vendors actively working to upstream their code. That code often does not take the form that mainline developers would like to see; some of it is just patches exporting symbols. That has created some tension in the development community, he said.

  • Vibrant Networking, Edge Open Source Development On Full Display at Open Networking & Edge Summit

    The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today marked significant progress in the open networking and edge spaces. In advance of the Open Networking and Edge Summit happening September 28-30, Linux Foundation umbrella projects LF Edge and LF Networking demonstrate recent achievements highlighting trends that set the stage for next-generation technology.

  • Vibrant Networking, Edge Open Source Development On Full Display at Open Networking & Edge Summit

    The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today marked significant progress in the open networking and edge spaces. In advance of the Open Networking and Edge Summit happening September 28-30, Linux Foundation umbrella projects LF Edge and LF Networking demonstrate recent achievements highlighting trends that set the stage for next-generation technology. [...] “We are thrilled to announce a number of milestones across our networking and edge projects, which will be on virtual display at ONES next week,” said Arpit Joshipura, general manager, Networking, Edge and IOT, at the Linux Foundation. “Indicative of what’s coming next, our communities are laying the groundwork for markets like cloud native, 5G, and edge to explode in terms of open deployments.”