Linux and Technology blog

October 17, 2006

Writing to NTFS

Filed under: Driver, Kernel, Linux, Technolgoy, Tutorials, Utilities — rakeshvk @ 5:49 pm

The Linux NTFS project has released a beta version of its fully open source userspace (using FUSE) 3G-Linux NTFS support driver. According to the developer, this driver beats hands down other NTFS support solutions performance-wise (including commercial Paragon NTFS driver and also Captive NTFS, which is using windows ntfs.sys driver under WINE).” That’s right, writing to NTFS even works. Soon it’ll mean one less recovery disk to keep around, I hope.

How to access NTFS from Linux

Choose one of the following three options:
1) Linux has an integrated kernel driver. It allows reading of files, and rewriting existing files. It does not support creation of new files or deletion of existing files. It works out of the box in most modern Linux distributions except Redhat/Fedora. For details on how to use it, see the “How to mount NTFS” wiki page. Click here if you are a Redhat/Fedora user.

2) ntfsprogs includes an improved driver, ntfsmount, which provides the same functionality as the kernel driver. Additionally it also supports basic cases of directory, symlink, device and FIFO file creation, deletion and renaming. Note: That doesn’t mean it always succeeds, it is still experimental and might just as well refuse to complete an operation in order to prevent corruption. See the ntfsmount page for more details.

3) On 07/14/2006, project member Szabolcs Szakacsits presented a new version of ntfsmount and libntfs, currently given the project title ntfs-3g. This version has full read/write capabilities, many bug fixes and improved performance. It has already been downloaded over 45,000 times, tested and regularly used by users with satisfaction over the last two months. Despite of that it is still a strong beta, and will upon (in some way or the other) merge also into the linux-ntfs ntfsprogs package.

The beta version of the ntfs-3g driver can be downloaded from http://mlf.linux.rulez.org/mlf/ezaz/ntfs-3g-20070920-BETA.tgz

October 16, 2006

Enhanced Linux filesystem nears production kernel

Filed under: Kernel, Software, Technolgoy — rakeshvk @ 4:51 pm

Ext3 has become one of the most popular Linux filesystems. However, with hard drives sneaking up on a terabyte, concerns exist that ext3 won’t be able to handle 21st-century storage requirements. With this in mind, the Linux kernel developers have just released the first real-world test version of ext4.

Andrew Morton, the well-known Linux developer, added the new experimental filesystem on Oct. 10 to the Linux kernel.

This new filesystem features support for storage up to for 1024 petabytes per volume. A petabyte is 250 (two to the fiftieth power) bytes. If that sounds insanely large, think again. Individual supercomputers such as Lawrence Livermore National Labs’s BlueGene/L already have over a petabyte of storage and several storage networks are reputed to have well over a dozen petabytes.

Read the full news

September 29, 2006

Linux: Suspend and Resume

Filed under: Kernel, Linux — rakeshvk @ 5:47 pm

A recent thread on the lkml explored the current state of suspend and resume in the Linux kernel. Nigel Cunningham responded to a patch for uswsusp exclaiming, “guys! Why can’t you see yet that all this uswsusp business is sheer lunacy?” He went on to reiterate his concerns that the important logic involved in suspending will take place in the kernel, and that trying to move it to userspace won’t work. Andrew Morton joined in, “I’d suggest that it’d be better to be expending the grey cells on making the present suspend stuff nice and solid, stable and fast,” going on to add, “right now a suspend-to-disk spends more time futzing around doing mysterious-but-probably-pointless stuff than it does writing memory to disk. I’ve no idea what it’s doing with all that time, but I’ll wager it’s not very useful to anyone ;)”

Read the full topic 

August 31, 2006

Guide To Hacking The Linux Kernel

Filed under: Kernel, Tutorials — rakeshvk @ 6:56 am

Welcome, gentle reader, to Rusty’s Unreliable Guide to Linux Kernel Hacking. This document describes the common routines and general requirements for kernel code: its goal is to serve as a primer for Linux kernel development for experienced C programmers. I avoid implementation details: that’s what the code is for, and I ignore whole tracts of useful routines.

Before you read this, please understand that I never wanted to write this document, being grossly under-qualified, but I always wanted to read it, and this was the only way. I hope it will grow into a compendium of best practice, common starting points and random information.  >>>>

August 24, 2006

Real Time Coming to Linux Real Soon

Filed under: Kernel, Linux, News — rakeshvk @ 9:20 am

Real Time operating systems have traditionally been a separate breed from mainstream ones.

Thanks to efforts to incorporate Real Time enhancements into Linux, standard mainstream Linux may well become a real, Real Time OS real soon.

A Real Time OS offers the promise of better response times and a degree of determinism not found in non-Real Time OS’s.

Real Time is often a requirement in embedded applications and control system such as those used in military and medical applications, as well as many other verticals.

According to at least one leading Linux vendor, though, Real Time has applicability across nearly the entire Linux landscape. >>>>

August 17, 2006

The Linux kernel map -2.6.18

Filed under: Kernel, Linux — rakeshvk @ 5:47 pm

Here’s a easy to follow flowchart for all those who say linux is complicated.

CFQ to become the default I/O scheduler in 2.6.18

Filed under: Kernel, News — rakeshvk @ 9:34 am

Judging by this commit, CFQ (Complete Fair Queuing) I/O scheduler will become the default one in the upcoming 2.6.18 kernel. For a long time, anticipatory scheduler has been the default, although even back in late 2004 there was some thinking about replacing it with CFQ. And it seems the time has finally come. CFQ scheduler has been gaining adoption since then, to the point that it’s the default I/O scheduler for RHEL 4, Suse, and other distros.

One of the coolest things about CFQ is that it features I/O priorities (since 2.6.13). That means you can set the I/O priority of a process so you can avoid that a process that does too much I/O (daily updatedb) starves the rest of the system, or give extra priority to a process that shouldn’t be starved by other processes, by using the ionice tool included in schedutils (since version 1.5.0).

If you find any problems with the new default scheduler, you can still continue using the AS scheduler, by switching to it at runtime (echo anticipatory > /sys/block/<disk>/queue/scheduler) or by using the elevator=as boot option.

August 7, 2006

Reiser4 and the politics of the kernel

Filed under: Kernel, News, Reviews — rakeshvk @ 6:31 pm

Why is the Reiser4 filesystem not in the Linux kernel? Recently, the question has been discussed on the kernel mailing list, and it’s not a pretty sight; anyone who imagines that kernel development is a rational discourse only needs to look at the exchange to be disillusioned. While both sides claim to be arguing technical merits, the discussion spills over into a debate about the advantages of established procedures and policies. It’s also turned into a clash of personalities.

Reiser4 is the successor to ReiserFS (a.k.a. Reiser3), a journaled filesystem that has been in the kernel since version 2.4.1, and that also faced a rocky road to inclusion. Both are developed by Namesys, a company fronted by Hans Reiser, with sponsorship from Linspire and the Defense Advance Research Projects Agency. According to Namesys, Reiser4 offers twice the speed of other filesystems, as well as greater efficiency in file allocation and military-grade security. It has attracted a loyal group of users, and, while not in the official kernel, is included in Andrew Morton’s experimental -mm kernel sources. >>>>


Reasons why Reiser4 is great for you:

  • Reiser4 is the fastest filesystem, and here are the benchmarks.
  • Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don’t, and they don’t corrupt due to half occuring. We do this without significant performance losses, because we invented algorithms to do it without copying the data twice.
  • Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down). This makes Reiser4 more space efficient than other filesystems because we squish small files together rather than wasting space due to block alignment like they do. It also means that Reiser4 scales better than any other filesystem. Do you want a million files in a directory, and want to create them fast? No problem.
  • Reiser4 is based on plugins, which means that it will attract many outside contributors, and you’ll be able to upgrade to their innovations without reformatting your disk. If you like to code, you’ll really like plugins….
  • Reiser4 is architected for military grade security. You’ll find it is easy to audit the code, and that assertions guard the entrance to every function.

V3 of reiserfs is used as the default filesystem for SuSE, Lindows, FTOSX, Libranet, Xandros and Yoper. We don’t touch the V3 code except to fix a bug, and as a result we don’t get bug reports for the current mainstream kernel version. It shipped before the other journaling filesystems for Linux, and is the most stable of them as a result of having been out the longest. We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3.

August 3, 2006

SGI reports Linux-aided world record

Filed under: Business & OSS, Kernel, Linux, News — rakeshvk @ 6:39 am

As the US computer manufacturer SGI reports, one of its Altix 4700 systems has outpaced the previous STREAM Triad benchmark record by a factor of 4, achieving a sustained memory bandwidth of 4.35 terabytes per second.

The STREAM Triad Benchmark, developed by the University of Virginia, is an approach to measuring memory bandwidth that employs datasets much larger than the available cache on any given system.

SGI’s test system was an Itanium system running under Novell’s Suse Linux Enterprise Server 10 made up of 1,024 CPUs and with 4 terabytes of main memory; a configuration that amounts to the largest single system image attainable on a Linux OS system. The system is meanwhile part of the Federal Republic’s high-performance computer at the Leibniz Computing Centre Munich (LRZ) in the district of Garching; the measurements had already been carried out on June 1. (Robert W. Smith) / (jk/c’t)

August 2, 2006

Linux initial RAM disk (initrd) overview

Filed under: Kernel, Linux, Tutorials — rakeshvk @ 5:22 pm

The Linux® initial RAM disk (initrd) is a temporary root file system that is mounted during system boot to support the two-state boot process. The initrd contains various executables and drivers that permit the real root file system to be mounted, after which the initrd RAM disk is unmounted and its memory freed. In many embedded Linux systems, the initrd is the final root file system. This article explores the initial RAM disk for Linux 2.6, including its creation and use in the Linux kernel.

What’s an initial RAM disk?

The initial RAM disk (initrd) is an initial root file system that is mounted prior to when the real root file system is available. The initrd is bound to the kernel and loaded as part of the kernel boot procedure. The kernel then mounts this initrd as part of the two-stage boot process to load the modules to make the real file systems available and get at the real root file system.

The initrd contains a minimal set of directories and executables to achieve this, such as the insmod tool to install kernel modules into the kernel.

In the case of desktop or server Linux systems, the initrd is a transient file system. Its lifetime is short, only serving as a bridge to the real root file system. In embedded systems with no mutable storage, the initrd is the permanent root file system. This article explores both of these contexts. >>>>

Older Posts »

Blog at WordPress.com.