Linux File System Fsck Testing -- The Results Are In

After an extended delay, the Linux File System fsck testing results can now be presented. The test plan has changed slightly from our kickoff article previous article. We will review it at the beginning of the this article, followed by the actual results. Henry Newman will be reviewing the results and writing some observations in the next article in this series. As always we welcome reader feedback and comments.

FSCK Testing Plan

It has been a while since we started the fsck project to test fsck (file system check) times on Linux file systems. The lengthy delay in obtaining the results is due to the lack of hardware for testing. The original vendor could not spare the hardware for testing. A number of other vendors were contacted and due to various reasons none of them could provide the needed hardware for many, many months if at all. In the end, Henry used his diplomatic skills to save the day, persuading Data Direct Networks to help us out. Paul Carl and Randy Kreiser from DDN contacted me and agreed to provide remote access to the hardware (thank you, DDN!).
Paul used a DDN SFA10K-X with 590 disks that are 450GB, 15,000 rpm SAS disks. He used a 128KB chunk size in the creation. From these disks he created a number of RAID-6 pools using an 8+2 configuration (8 data disks and 2 parity disks). Each pool is a LUN that is 3.6TB in size before formatting or actually 3,347,054,592 bytes as reported by "cat /proc/partitions". The LUNS were presented to the server as disk devices such as /dev/sdb1, /dev/sdc1, /dev/sdd1, ..., /dev/sdx1 for a total of 23 LUNs of 3.6TBs each. This is a total of 82.8 TBs (raw). The LUNs were combined using mdadm and RAID-0 to create a RAID-60 configuration using the following command:

mdadm -- create /dev/md1 -- chunk=1024 -- level=0 -- raid-devices=23 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1 /dev/sdm1 /dev/sdn1 /dev/sdo1 /dev/sdp1 /dev/sdq1 /dev/sdr1 /dev/sds1 /dev/sdt1 /dev/sdu1 /dev/sdv1 /dev/sdw1 /dev/sdx1

The result was a file system with about 72TB using "df -h" or 76,982,232,064 bytes from "cat /proc/partitions". A second set of tests were run on storage that used only 12 of the 23 LUNs. The mdadm command is,

mdadm -- create /dev/md1 -- chunk=1024 -- level=0 -- raid-devices=12 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1 /dev/sdm1

The resulting file system for this configuration is about 38 TBs using "df -h".
The server used in the study is a dual-socket, Intel Xeon system with Nehalem processors (E5520) running at 2.27 GHz and an 8MB cache. The server has a total of 24GB of memory, and it was connected to the storage via a Qlogic Fibre Channel FC8 card connected to an FC switch that was connected to the storage. The server ran CentOS 5.7 (2.6.18-274 kernel). The stock configuration was used throughput the testing except for one component. The e2fsprogs package was upgraded to version 1.42, enabling ext4 file systems larger than 16TB to be created. This allows the fcsk performance of xfs and ext4 to be contrasted.

Related Articles

• The State of File Systems Technology, Problem Statement
• Test Plan for Linux File System Fsck Testing

Building the file systems was done close to the default behavior that many system admins will adopt -- using the defaults. The commands for building the file systems are:

• XFS: /sbin/mkfs.xfs -f /dev/md1
• EXT4: /sbin/mke2fs -t ext4 -F /dev/md1

Mounting the file systems involved a little more tuning. In the case of XFS, I used the tuning options as stated by Dell, XFS -- rw,noatime,attr2,nobarrier,inode64,noquota. In the case of ext4, the mounting options used are defaults,data=writeback,noatime,barrier=0,journal_checksum.
The journal checksum was turned on within ext4 since I like this added behavior.

Filling the File System

One of the keys to the testing is how the file system is filled. This can be a very time consuming process because you must create all of the files in some sort of order or fashion. For this testing, fs_mark was used. Ric Wheeler at Red Hat has been using it for testing file systems at very large scales (over 1 billion files). Fs_mark wasn't used for testing the file system in this article, but rather, it is used to fill the file system in a specific fashion. It uses one or more base directories and then creates a specified number of subdirectories underneath them that are filled with files. You might think of this as a single-level of subdirectories. It is much more complicated to create specific subdirectory depths and number of files since that configuration depends on the specific users and situation. You could also use some sort of random approach with the hope that a random distribution approximates a real-world situation. It is virtually impossible to have a representative file system tree that fits most general situations, and the single-level deep directory tree used here should represent one extreme of file systems -- a single subdirectory level.
One of the nice features of fs_mark is that it is threaded so that each thread produces its own unique directory structure with a single layer of subdirectories underneath a base directory that contains a fixed number of files. Fs_mark also allows you to specify the number of files per thread so that you can control the total number of files. Although the server has eight total cores, running eight threads (one per core) it resulted in the OS swapping. When the number of threads is reduced to three, the server did not swap, and the file creation rate was much faster than running eight threads with swapping.
Using three threads causes some issues because it is an odd number. This made it impossible to determine an integer number of files per thread, as using the old file counts was not possible. The number of files per thread was changed to a reasonable integer number that is close to the original numbers of 100,000,000, 50,000,000, and 10,000,000. The numbers chosen were: 105,000,000, 51,000,000, and 10,200,000.
The goal for all fs_mark commands was to fill the file system to the specified number of files while filling about 50 percent of the file system. The following fs_mark command lines were used to fill the file system for 72TB:

• ./fs_mark -s 400000 -L 1 -S 0 -n 35000000 -D 35000 -N 1000 -t 3 -k -d /mnt/test
• ./fs_mark -s 800000 -L 1 -S 0 -n 17000000 -D 17000 -N 1000 -t 3 -k -d /mnt/test
• ./fs_mark -s 4000000 -L 1 -S 0 -n 3400000 -D 3400 -N 1000 -t 3 -k -d /mnt/test

The commands for filling the 38TB file systems were:

• ./fs_mark -s 200000 -L 1 -S 0 -n 35000000 -D 35000 -N 1000 -t 3 -k -d /mnt/test
• ./fs_mark -s 400000 -L 1 -S 0 -n 17000000 -D 17000 -N 1000 -t 3 -k -d /mnt/test
• ./fs_mark -s 2000000 -L 1 -S 0 -n 3400000 -D 3400 -N 1000 -t 3 -k -d /mnt/test

Notice that the number of files per directory is a constant (-N 1000 or 1,000 files).
After the file system was filled using fs_mark, it was unmounted, and the file system check was run on the device. In the case of xfs, the command is,

/sbin/xfs_repair -v /dev/md1

Related Articles

• The State of File Systems Technology, Problem Statement
• Test Plan for Linux File System Fsck Testing

For ext4, the file system check was,

/sbin/e2fsck -pfFt /dev/md1

Notice that the device /dev/md1 was the target in both cases.

Additional FSCK Tests

DDN was kind of enough to offer additional testing time so I decided to try some tests that stretched the boundaries a bit. The first test was to create an XFS file system with 415,000,000 files and filling about 40 percent of the file system on the 72TB file system. The second test was to try to increase the fragmentation of the file system by randomly adding and deleting directories using fs_mark for the 105,000,000 file case also on the 72TB file system.
For the first test where 415,000,000 files were created, the original goal was to test 520,000,000 files in five stages of 105,000,000 files (creating 520,000,000 all at once caused the server to swap badly). However, due to time constraints, only four of the five stages could be run (fs_mark ran increasingly slower the more files were on the system). The final number of files created was 420,035,002 which also includes all "." and ".." files on the directories.
For the second test, approximately 105,000,000 files were created on an XFS file system in several steps. A total of five stages were used where 21,000,000 files were added at each stage using fs_mark (a total of 105,000,000 files). In between the stages, a number of directories were randomly removed, and the same number of directories anf files were replaced using fs_mark on randomly selected directories. The basic process is listed below:

1. Use fs_mark to create 21,000,000 files using,
   • 3 threads of 7,000,000 files each
   • 7,000 directories
   • 1,000 files per directory
2. Randomly remove 700 directories and their files ("rm -rf")
3. use fs_mark to add 700 directories with 1,000 files each to 700 randomly chosen existing directories (one directory is added to one existing directory)
4. Use fs_mark to create 21,000,000 more files (42,000,000 total at this point)
5. Randomly remove 1,400 directories and their files
6. Use fs_mark to add 1,400 directories with 1,000 files each to 1,400 randomly chosen existing directories
7. Use fs_mark to create 21,000,000 more files (63,000,000 total at this point)
8. Randomly remove 2,100 directories and their files
9. Use fs_mark to add 2,100 directories with 1,000 files each to 2,100 randomly chosen existing directories
10. Use fs_mark to add 21,000,000 more files (84,000,000 total at this point)
11. Randomly remove 2,8000 directories and their files
12. Use fs_mark to add 2,8000 directories with 1,0000 files each to 2,800 randomly chosen existing directories
13. Use fs_mark to add the final 21,000,000 files (105,000,000 total at this point)
14. Randomly remove 3,500 directories and their files
15. Use fs_mark to add 3,500 directories with 1,000 files each to 3,500 randomly chose existing directories

Because of the random nature of selecting the directories, it is possible to get some directories with many more files than others. However, the total number of files won't be 105,000,000 since of the random nature of selection for deletion and insertion. If we count all fo the files including the "." and ".." files we find that the process created 115,516,127 files.

FSCK Results

The table below lists the file system repair times in seconds for the standard matrix cases as specified in the previous article but with the new number of files. These times include all steps in the file system checking process.

File System Size (in TB)	Number of Files (in Millions)	XFS - xfs_repair time (Seconds)	ext4 - fsck time (Seconds)
72	105	1,629	3,193
72	51	534	1,811
72	10.2	161	972
38	105	710	3,372
38	51	266	1,358
38	10.2	131	470

Related Articles

• The State of File Systems Technology, Problem Statement
• Test Plan for Linux File System Fsck Testing

The FSCK time for the additional tests are listed below:

• 415,000,000 file case:11,324 seconds
• Fragmented case: 676 seconds

Notice that the 415,000,000 case took 6.95 times longer than the 105,000,000 file case even though it had four times as many files. During the file system check the server did not swap, and no additional use of virtual memory was observed.
The "fragmented" case is interesting because it took less time to perform the file system check than the one-level directory case. The original case took 1,629 seconds and the fragmented case took only 676 seconds -- about 2.5 times faster. Time did not allow investigating why this happened.
In the next article in this seriesHenry writing about his observations of the results. Please be sure to post your comments about these testing results.

A Big Thank You

At first glance it seemed simple a vendor could provide about 80TB to 100TB of raw storage connected to a server for testing, but this turned out not to be the case. It was far more difficult than anticipated. I would be remiss if I didn't thank the people who made this possible: Of course Henry Newman for pushing various vendors to help if they could. Thanks go to Paul Carl and Randy Kreiser from DDN who greatly helped in giving me access to the hardware and helped with the initial hurdles that crop up. Thanks also to Ric Wheeler who answered several emails about using fs_mark and about Linux file systems in general. He has been a big supporter of this testing from the beginning. Thanks also to Andres Dilger from Whamcloud who provided great feedback and offers of help all of the time.
Jeff Layton is the Enterprise Technologist for HPC at Dell, Inc., and a regular writer of all things HPC and storage.
Henry Newman is CEO and CTO of Instrumental Inc. and has worked in HPC and large storage environments for 29 years. The outspoken Mr. Newman initially went to school to become a diplomat, but was firmly told during his first year that he might be better suited for a career that didn't require diplomatic skills. Diplomacy's loss was HPC's gain.

Test Plan for Linux File System Fsck Testing

Building on Henry's Problem Statement, this article will present the test plan for performing fsck tests on Linux file systems. The goal is to test fairly large file systems that might be encountered on large systems to determine the status of file system check (fsck) performance. We ask and appreciate your feedback on the test plan.

Introduction to Fsck Testing

Testing storage systems or any aspect of IT systems is definitely not an easy task. It takes careful planning, testing and hardware for proper benchmarks. Even if we are trying to be careful, it can be easy to forget, omit (either by design or as an accident), or misconfigure systems and benchmarks. Hence, the results are, unfortunately, less useful and maybe don't meet the original requirements. Henry and I often call these Slimy Benchmarking Tricks (SBTs). The end result is that good tests or benchmarks are difficult to do well. Perhaps as a consequence, much of the benchmarking we see today is of very poor quality, to the degree that it is virtually useless and more often than not, entertaining (and sometime frustrating).

Even if the benchmarks are done well, there is still the problem of correlating the benchmarks/tests to your application workload. This is true for computing-oriented benchmarks, such as taking something like H.264 encoding tests and determining how the benchmarks correlate to your weather modeling applications. This is also true for storage benchmarks. How do Postmark results correlate to an MPI-IO application that is doing astrophysics simulation? Or how do IOR results correlate to my database performance? The answer is as simple as it is nebulous--it depends.

There is no magic formula that tells you how to correlate benchmarks to real application workloads and more specifically, your application workload. The best predictor of your application workload's performance is, believe it or not, your application workload. However, it's not always possible to test your workload against storage solutions that range in terms of hardware, networking, file systems, file system tuning, clients, OS and so on. This is why we rely on benchmarks or tests to as an indicator of how our workload might perform. Typically, this means you have to take these benchmarks, run them on your existing systems, and compare the trends to the trends of your application workloads.

For example, you could take your existing systems and run a variety of benchmarks/tests against them--IOR, IOzone, Postmark and so on--and run your workloads on the same systems. Then, you can compare the two sets of results and look for correlation. This might tell you which benchmark(s) track closest to your application, indicating which benchmark/test you should focus on when you look for data about new hardware or new file systems. But this task isn't easy and it takes time--time we usually don't have. However, to effectively use benchmarks and tests we need to understand this correlation and how it affects us. Otherwise it's just marketing information.

Keeping these ideas in mind, our goal is to examine the fsck (file system check) performance of Linux file systems by filling them with dummy data, and then executing an appropriate file system check. This article describes the approach and the details we will be using in running these tests. Fortunately, in our case, the benchmark/test is fairly simple--fsck wall clock time-- so this should make our lives, and yours, a bit easier.
The following sections go over the details of the testing. Please read them carefully, and we encourage your feedback on the test plan with suggestions/comments.

Benchmark/Test Process

I've written elsewhere about benchmarking storage systems. We will try to adhere to the tenants presented in the article and be as transparent as possible. However, if you have any questions or comments, we encourage you to post them.

Related Articles

• The State of File Systems Technology, Problem Statement
• Test Plan for Linux File System Fsck Testing

The basic plan for the testing only has three steps:

1. Create the file system
2. Fill the file system
3. Run fsck and time how long it takes

That's pretty much it--not too complicated at this level, but the devil is always in the details.
Since our goal is to understand the fsck time for current Linux file systems, we will run several tests run to develop an understanding of how the fsck performance scales with the number of files and file system size. We'll test both XFS and ext4 for three values of the number of files: 1) 100 million files, 2) 50 million files and 3) 10 million files.

According to the Red Hat documents Henry previously mentioned, XFS is supported to 100TBs. The testing hardware we have access to limits the total file system to about 80TBs, formatted (more on that in the next section). We'll also test at 40TBs (half that size). For testing ext4, the same Red Hat document says that only a 16TB file system is currently supported. To prevent running up against any unforeseen problems, we'll test with a 10TB file system and a 5TB file system.

An fsck for ext4 for both of these file system sizes should not take a long to run, since there are very few spindles and a large number of files. Consequently, we will run these tests last.
Overall, the fsck tests that are to be run are on the following combinations.

1. 80TB XFS File System
   • 100 Million files
   • 50 Million files
   • 10 Million files
2. 40TB XFS File System
   
   • 100 Million files
   • 50 Million files
   • 10 Million files
3. 10 TB ext4 File System
   
   • 100 Million Files
   • 50 Million Files
   • 10 Million Files
4. 5TB ext4 File System
   
   • 100 Million Files
   • 50 Million Files
   • 10 Million Files

For each of these combinations, three basic steps will be followed--

1. Create the file system
2. Fill the file system
3. Run fsck and time the results

For ext4, we will use fsck.ext4 to execute the file system check. For XFS, we will use xfs_repair (Note: xfs_check just walks the file system and doesn't do repairs. We want to run tests using the same commands an admin would be using, which is xfs_repair.).

One of the key pieces in the testing is how to fill the file system. The tool we will be using is called fs_mark. It was developed by Ric Wheeler (now at Red Hat) to test file systems. Fs_mark will test various aspects of the file system performance, which is interesting, but not the focus of this test. However, in running the tests, fs_mark will conveniently create the file system, which is what is needed.

Fs_mark
Using fs_mark, the file system is filled and tested. There are a large number of options for fs_mark, but we will focus on only a few of them. An example of command line for creating 100 million files is the following:

# fs_mark -n 10000000 -s 400 -L 1 -S 0 -D 10000 -N 1000 -d /mnt/home -t 10 -k

where the options are:

• -n 10000000: The number of files to be tested per thread (more on that later)
• -s 400; Each file will be 400KB
• -L 1: Loop the testing once (fs_mark testing)
• -S 0: Issue no sync() or fsync() during the creation of the file system. Since fs_mark is not being used for testing file systems, we just care about creating the file system quickly
• -D 10000: There are 10,000 subdirectories under the main root directory
• -d /mnt/home: The root directory for testing; for this particular test, we are using only 1 root directory
• -N 1000: 1,000 files are allocated per directory
• -t 10: Use 10 threads for building the file system
• -k: Keep the file system after testing
• -N 10,000: Allocate 10,000 files per directory

With these options, there are a total of 1,000 files per directory, and there are 10,000 directories. This results in a total of 10 million files. However, note that the number of files specified by the "-n" option lists only 10 million files because each thread will produce "-n" files. Since we have 10 threads and we have 10 million files per thread, this results in a total of 100 million files.

Since we have 100 million files and each file is 400KB, the file system uses a total of 40TBs. This is about half of the 80TBs for the largest file system. With the goal of filling at least 50 percent of the file system for the specified number of files, the resulting file sizes are listed below.

1. 80TB XFS File System
   • 100 Million files: 400KB file size
   • 50 Million files: 800 KB file size
   • 10 Million files: 4,000 KB (4MB) file size

2. Related Articles

   • The State of File Systems Technology, Problem Statement
   • Test Plan for Linux File System Fsck Testing
   40TB XFS File System
   
   • 100 Million files: 200KB file size
   • 50 Million files: 100KB file size
   • 10 Million files: 2,000 KB (2MB) file size
3. 10 TB ext4 File System
   
   • 100 Million Files: 5KB file size
   • 50 Million Files: 10KB file size
   • 10 Million Files: 50KB file size
4. 5TB ext4 File System
   
   • 100 Million Files: 3KB file size
   • 50 Million Files: 6KB file size
   • 10 Million Files: 30KB file size

All of the tests except the last one use 50 percent of the space. The last one uses 60 percent of the space.
When possible, we will repeat the tests several times so we can report the average the standard deviation. In between tests, the file system will be remade and the fs_mark will be rerun to fill the file system. Due to the possibly large amount of time to fill the file system and run fsck, it is possible that only a few tests will be run.

Hardware
Dell has been kind enough to supply us with hardware for the testing. The hardware used is its NSS solution that uses xfs. The configuration consists of a single NFS gateway with two Intel 4-core processors, either 24 or 48 TBs of memory, and two 6Gbps RAID cards that are each connected to a daisy-chained series of JBODs. The JBODs have twelve 3.5" drives. The drives used are 7.2K rpm, 2TB NL-SAS drives. Each JBOD uses RAID-6 across 10 of the drives for actual capacity, leaving the other two drives for parity. So each JBOD provides 20TBs of capacity. The RAID cards use RAID-60 on their particular set of JBODs (RAID-6 within each JBOD and RAID-0 to combine them). Then LVM is used to combine the capacity of the two RAID cards into a single device used for building the file system.

For the 80TB configuration, a total of 48 drives is used (40 for capacity and 8 for parity). For the 40TB-configuration, a total of 24 drives are used (20 for capacity and 4 for parity). The smaller configurations used in the ext4 testing just use less of capacity of the 40TB configuration using LVM.

Summary and Invitation for Comments
This article is really the test plan that executes the ideas embodied in Henry's article. The focus is on testing the fsck time for Linux file systems, particularly xfs and ext4, on current hardware. To gain an understanding of how fsck time varies, several file system sizes and number of files will be tested.

We will be using fs_mark to fill the file systems and then just run the appropriate file system check and time how it long it takes to complete. It's a pretty straightforward test that should give us some insight into how fsck performs on current Linux file systems.

We want to encourage feedback on the test plan. Is something critical missing? Is there perhaps a better way to fill the file system? Is there another important test point? Speak now or forever hold your peace.

Jeff Layton is the Enterprise Technologist for HPC at Dell, Inc., and a regular writer of all things HPC and storage.

4 Best Free Linux Script Writing Tools

Script writing is the art and craft of writing scripts for the general public. The script can take the form of musicals, plays, novels, films, television programmes, and more. Each time you watch a show on television, visit the cinema, or read a book you are consuming the trials and tribulations of a script writer.
Script writing software is not designed to make writing judgments such as avoiding the use of cliches, jargon, and journalese, nor does it help with the rhythm and balance of the piece. Instead this type of software concentrates on helping the writer to present the text in an appropriate format.
If you have your heart set on writing a Broadway script, a Hollywood screenplay, or a best selling novel, good script writing software will save precious time. Unfortunately, there is currently a miserly selection of mature, open source script writing software available for Linux. The heavyweight in this category of software is Final Draft, a professional, industry-standard screen writing application. However, it is commercial software and not available for Linux. However, the Linux community has still mustered some credible open source alternatives.
To provide an insight into the quality of software that is available, we have compiled a list of 4 competent free Linux script writing tools. They include some powerful tools, a document class, and a plugin. Hopefully, there will be something of interest here for any budding script writer.
Now, let's explore the 4 script writing tools at hand. For each title we have compiled its own portal page, a full description with an in-depth analysis of its features, a screenshot, together with links to relevant resources and reviews.

Script Writing Tools
Celtx	Screenwriting software for writing and formatting a screenplay
Trelby	Simple, powerful, full-featured program for writing movie screenplays
LyX	The Hollywood document class suitably equips LyX for script writing
Pago	Screenwriting plugin for the Vim text editor

Virtualize everything (except in these four scenarios)

Takeaway: Virtualization should be the de facto standard in deploying workloads today. However, there are valid exceptions. Rick Vanover lists four of them in this blog post.

Don’t get me wrong, I’m 100% pro virtualization. But, I do realize that there are some scenarios where a virtual machine isn’t the best solution. I find the use cases fewer and farther between, but they are out there today. Here are a few scenarios where I still see virtual machines not fitting the bill:

#1 Highest performance
As a general rule, the native hardware versus virtual machine performance discussion is a no contest. You “can” make a virtual machine outperform a physical machine running on native hardware; but not in a like-for-like configuration. If you need the utmost performance; a physical machine may still be the way.

#2 Application requirements
Again, I’m a VMware and Hyper-V guy, so I want to see everything end up as a virtual machine. But really – in today’s modern times – do we still have application requirements that don’t support virtual machine configurations? What really needs to change is the application, then. We can do so much more with the application as a virtual machine. While I know there are applications that don’t support virtualization, they are there. Let’s work on removing them.

#3 Application maturity
Just as I critique the application in the previous point, a mature application that is fully stateless is a welcome change to the normal application profile. There are a number of private cloud solutions that simply boot up (usually via PXE) and take on a role in a protected arrangement for a larger application. These larger applications tend to be very resource-intensive and dynamic in nature. Further, the data for these solutions is usually distributed and self-protected to the level of equipment that is in play.

#4 Full separation
One of the critical design elements of virtualization (and any infrastructure technology for that matter) is to introduce as many layers of separation as possible for redundancy. While I’m not a fan of holding on to the single physical domain controller, there are valid physical machine configurations for full separation from the virtual infrastructure. This can include security tools or backups of the virtual machines. In my opinion, the reasons are getting weaker. But, if we deploy solutions on virtual machines that really don’t fit in a virtualized infrastructure; that may be something to avoid.

Do you have situations where you can’t use a virtual machine for new deployments? Share your exceptions to the norm below.

Understanding Open Source Licensing

Open Source software generally rely on content licensing, the terms of which can be baffling for many. In this article, we demystify the major licenses from an enterprise perspective

In works licensed under an open source license, anyone is permitted to modify and redistribute, as long as a given set of criterion are met. But, that's the simple definition. Life in the open source licensing world is much more complex than that. Before going any further, let us catch a glimpse of what an open source license means and what are its associated caveats. Strictly speaking, an open source license must comply with the definition specified by Open Source Initiative, as laid out at http://opensource.org/ docs/definition.php:

To quote from the definition itself, “The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.”

Thus, if you license your work under an open source license, you do not have a commanding influence over who gets to use your work and in what manner the said person decides to use it. Surely, you can restrict commercial/derivative usage of your work, but in all likelihood, you cannot essentially make an income (or, at least a GOOD income) using open source licenses.

Further more, another important aspect of open source licenses is the permission 'to fork'. Forks of an open source project are derivatives of the project which evolve from it, but take a different line of growth and establish an altogether separate identity.

Arguably, the prime reason why developers tend to opt for open source licenses is that it lets their software roll on as a group or community exercise, and this in turn enhances productivity manifolds. For instance, Acquia Network, the parent organization behind Drupal, currently consists of 160 employees. Obviously, a company of that size cannot sustain a mammoth project such as Drupal. However, Drupal itself being open source, is helped by the numerous volunteers from the community. Similarly, WordPress rides the wagon of a super-active community while its parent organization, Automattic, concentrates on select issues.

Open source licenses nowadays come in multiple versions. Wikipedia has a rather incomplete list of some of the major free licenses at http://en.wikipedia.org/wiki/Free_software_license While all such licenses cater to diverse purposes with the same goal ('freedom'), we shall restrict ourselves to only the major ones for the sake of simplicity. From a small/medium enterprise's point of view, the noteworthy licenses include GPL/LGPL, MPL, Apache License and BSD License.

A bird's eye view on licenses

Before going any further, let us spend some time getting an overview of each major license named above. The technical and tactical details of these licenses can be adjudged after reading each, and the links for the same can be found at the website of OSI.

For an SME, GNU General Public License, or GPL as it is popularly called, is a well known license. It prohibits proprietary forking of the software, is easily understandable, and universally respected. It is also one of the most restrictive Open Source licenses, and the term 'restrictive' here applies more to enterprise usage, as well shall see later on. Also, GPL is the license behind Linux kernel.

MPL, or Mozilla Public License, as the name suggests, is Mozilla's version of GPL, though in a slightly less restrictive manner. For an enterprise, software licensed under MPL mean that the code can be used, re-used and distributed – all in a commercial environment. However, just like the GPL, MPL does not blend well with proprietary licenses.

If your enterprise comes across a software licensed under the BSD license, breathe a sigh of relief! You're in safe hands – you can happily use the BSD licensed-work in any commercial/non-commercial project, or even blend it with a proprietary fork. BSD license is known for its less restrictive nature. Your work is still copyrighted, and the project remains open source, but you do not even need to make the entire source code public in the first instance.

The Apache License, on the other hand, strikes a compromise between BSD license and GPL. You can still use such software in an enterprise environment, but unlike a BSD license, Apache does provide an explicit license clause for patents (though such clauses do not generally matter much for a small enterprise).

Another point worth noting here is the recent trend to 'dual-license' or 'multi-license' software. This happens when someone creates a fork of an existing project, but the said project's license may not be compatible with the newly created software's purpose or targeted usage.

In such a case, it becomes imperative to create a dual-licensed or even multi-licensed work. For example, MySQL is licensed under GPL. By its very definition, GPL does not allow commercial and/or proprietary forks. Thus, if one wishes to create a commercial yet non-proprietary software that incorporates usage of or even embeds MySQL, he will need to create a dual license for the software.

   Now that we have discussed the major licenses and the crux of their nature, we shall take a closer look at the info an enterprise needs to possess about the most popular open source license – GPL.

GNU GPL: what an organization should know

Before we proceed, let us understand the way software licensing works. A software is comparable to a book. Now, the authors (programmers) write the book (software), and get it copyrighted (proprietary). The book then comes out in the market and the readers (end-users) obtain it. If it is a proprietary book, they can read it, and stop at that. There may also be certain restrictions, that they can only keep one copy of the book, and cannot offer it to their friends or get it photocopied (piracy). Further more, super-closed licensed books may also come with regulations that forbid readers from reading the book at public places – they must read the book only at their office/home (use the software only on personal machines).

However, if the book comes with a GPL license, and belongs to the copyleft community, they can read it, and even pass it on, but they cannot create a fan-fiction replica of the book and attempt to sell it, without acknowledging the original book and GPL itself. Similarly, as the additional chapters (updates/fixes/patches) are released, they get appended to the book, and the responsibility lies with the reader to obtain the newer chapters.

Very clearly, GPL adds an altogether new dimension to the concept of copyleft and open source. In today's software world, GPL is one of the standard mechanisms to ensure that programmers are credited for their hard work and at the same time the entire community benefits from their innovations.

For a small/medium enterprise, an open source license matters in the sense that the programmer's intellectual property is not violated and, at the same time, productivity is not sacrificed due to an otherwise restricting proprietary 'legal talk'. All in all, open source licenses are a boon for organizations. However, unlike other open source licenses which are pretty straight-forward, GPL deserves slightly closer scrutiny to avoid unwanted hassles. Perhaps the sole irritant is the concept of 'derivatives' in GPL.

Generally, SMEs tend to pick up GPL licensed works assuming them to be as open source as any works under any other license. According to GPL v3, a derivative of a software is “one that is linked, statically or dynamically, to the original work”. However, this definition itself is considered vague, especially in an enterprise environment. For instance, your enterprise is using a derivative of an original GPL licensed work, with the difference being that the original software catered to a general audience while this derivative software caters especially to SMEs. Now, the two software are indeed linked, but only for the name sake. The original software does not target SMEs, while the newer one does. And as it goes without saying, you are employing this software in a commercial environment. However, philosophically, the newer software is still bound by GPL and there are limits to what you can do with it in a commercial usage scenario.

A good example of this situation is Joomla! The CMS is licensed under GPL, and by its definition, the associated themes and extensions must also be under GPL. However, a theme provider catering especially to enterprise/corporate websites once released a few themes (copyrighted, non-GPL) without paying heed to this catch. The outcome? Enterprises using the said themes were forced to change the look of their websites (consider it in terms of enterprise web identity, expenditure, etc). Ever since then, Joomla! community takes care to specify that any themes/extensions created for Joomla! must have code licensed under GPL (additional media such as animations, images and graphics can be non-GPL).

The cure to the above problem is as simple as the problem itself – keeping the eyes open! The concept behind GPL is simple – once the parent software is GPL, the offspring must at least acknowledge GPL. If it does so, it is safe for enterprise usage. 

أيها الزوج... أيتها الزوجة

أيها الزوج...

زوجتك ليست بحاجة فقط إلى النفقة والسكن

 لكنها أيضا بحاجة إلى كلمة جميلة

 وقلب حنون

 وعاطفة تملأ قلبها

 ورحمة تنسيها تعبها

 أيتها الزوجة..

 لا تغرك قسوته

 ولا تصدقي جلافته

 ففي داخله طفل صغير

 يحتاج للحب والحنان والعطف والرعاية!!

 فتعاملي مع داخله تجديه إنسانا آخر!!

وعشان كده مصر يا ولاد حلوة الحلوات

د. أيمن الجندى    ١٢/ ٣/ ٢٠١١ لم أملك نفسى من البكاء وأنا أقرأ هذا المقال الودود عن أمنا الحبيبة مصر، الذى كتبه الأديب السعودى «محمد الرطيان» ونشره فى جريدة «المدينة» السعودية، واختار له هذا العنوان الجذاب «وعشان كده مصر يا ولاد حلوة الحلوات». أشكره من أعماق قلبى باسم مصر وكل عشاق مصر. أترككم مع المقال النثرى البديع.                                       ■ ■ ■ إن كانت مصر (أم الدنيا).. فهى من باب أولى أم للعرب جميعا. وأى عربى لا يحب مصر فتأكدوا أن فى قلبه خللا ما.. وأى عربى يكرهها فتأكدوا أنه ابن عاق!                                       ■ ■ ■ عودوا لطفولتكم أيها العرب: أول طبيب عالجكم.. مصرى. أول معلم درّسكم.. مصرى. أول كتاب قرأتموه.. كتبه مصرى وطبعته مطبعة مصرية. أولى حركات التنوير.. كانت تأتى من مصر. أولى الثورات.. مصرية. أول الشهداء.. مصريون. وأنا أحب مصر بكل ما فيها: من غلابة، وأناس طيبين، وفقراء. ورغم أنهم يعيشون فى المقابر يعرفون كيف يضحكون ويؤلفون النكات. أحبها: بعلمائها، ومثقفيها، ودعاتها، وفنانيها... ولا تقولوا لى: لا يجتمع فى قلب مؤمن حب (وجدى غنيم) و(محمد منير) لأننى أعلم بقلبى منكم.                                       ■ ■ ■ إنها مصر التى استطاعت أن تُصدّر لنا (لهجتها) كأنها لغة ثانية لنا.. وهى تخبئ روحها الحلوة فى لهجتها. إنها مصر التى تشعرك من أول لقاء: «كأنها واحدة من العيلة».. مصر التى تدخلها كأنك تدخل بيتك.                                       ■ ■ ■ كتبت سابقاً: إذا غنّت مصر.. رقص العرب. وإذا أنجبت «عمرو دياب» ستجد له نسخة فى كل عاصمة! وإذا غنى «عبدالحليم» – خليّ السلاح صاحى – أخرج العرب كل أسلحتهم من مخازنها! وصار رمى اليهود فى البحر خياراً استراتيجياً لكل العرب. أما إن جنحت للسلم، فاعلم أنه – حتى مقديشيو – سيصبح السلام خيارها (وبطيخها) الاستراتيجى! إنها مصر: إذا «تحجبت» سيصبح «الحجاب» أكثر الأزياء رواجاً وإذا أطلقت لحيتها فسيقل عدد الحلاقين من طنجة إلى ظفار وإذا خرجت للشارع وهى تحمل بيدها قنبلة وساطورا.. فاعلم أنك سترى هذا المشهد بعد سنة، سنتين، عشر.. فى شوارع أخرى. و: إنها مصر.. البهيّة.. الولاّدة: تنام، ولكنها لا تموت.                                       ■ ■ ■ يا رب النيل..احفظ بلاد النيل والمواويل من الجفاف. يا رب الغلابة.. احفظ الغلابة من المعتدين. يا رب مصر.. احفظ لنا أمن مصر.                                       ■ ■ ■ انتهى المقال. قولوا معى: «آمين».

اللهم إحفظ مصر وأهلها