/dev/blog

Unlike MySQL and other SQL dialects, apache derby doesn’t support the AUTO_INCREMENT keyword. To create an auto incremented filed in derby, you can use

CREATE TABLE customer
(
id INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1),
name VARCHAR(40) NOT NULL,
address VARCHAR(1024),
city VARCHAR(30),
CONSTRAINT primary_key PRIMARY KEY (id)
) ;

The value of id is now incremented automagically on every insert. You don’t have to specify it manually in the insert command

INSERT INTO customer(name , address, city)
   VALUES('Mr. Peanutbutter', '221 W 31st St', New York City);

For instruction on how to create auto incremented fields in other SQL dialects, have a look at the SQL Dialects Reference.

Mounting an ext3 partition using ext4 fs drivers will usually speed-up your filesystem without actually changing the on-disk structures. Therefore it’s possible to revert to the ext3 driver without any problem. This allows you to easily benefit from delayed allocation (delalloc) and multi-block allocation (mballoc).

Further performance enhancements are possible if you do change the on-disk structure, e.g. by using extents. The downside is that you can’t mount the filesystem any longer with kernel lacking ext4 support and you can’t revert.

To enable ext4 features on an existing ext3 filesystem, invoke:

tune2fs -O extents,uninit_bg,dir_index /dev/DEV 

Unfotunately, features like flex_bg and >16TB fs support can only be enabled at format time¹.

Your filesystem is now indeed converted to ext4, however, only files that are written after conversion will benefit from ext4 extends. Existing files would have to be rewritten. e4defrag is being developed to take care of this but in now meant for production environments as of now.

A workaround would be to use chattr to rewrite the files using extends. From the archlinux wiki:

find /home -xdev -type f -print0 | xargs -0 chattr +e
find /home -xdev -type d -print0 | xargs -0 chattr +e

It is being recommended though, “to test this command on a small number of files first, and check if everything is going all right. It may also be useful to check the filesystem after conversion.“². Please note their warnings about mercurial repositories and hardlinks in general, too.

[1] https://wiki.archlinux.org/index.php/Ext4#Migrating_files_to_extents
[2] https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4

In certain situations where you don’t have physical access to your server it can be quite helpful to know how to install a new os without physical media like CD/DVD/USB or pxe.

This brief example shows you, how to bootstrap a rootserver (that of course already has a linux os installed that you can access through ssh) to install Fedora 15.

First, you’ll need the initial ramdisk and the kernel images:

cd /boot/
wget http://dl.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/x86_64/os/isolinux/initrd.img
wget http://dl.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/x86_64/os/isolinux/vmlinuz

Next, you add a new boot target to your grub.conf:

[...]
 title Fedora Install
  root (hd0,0)
  kernel /vmlinuz vnc vncpassword=SECRET ksdevice=eth0 ks=http://server/ks.cfg
  initrd /initrd.img

Don’t forget to change the boot target (default=n) in your grub.conf, too.

After rebooting the server, you can observe the installation process with your favourite vnc viewer.

click for full size image

By default, 5% of a new ext2/3/4 partition will be reserved for important root processes and for fs performance reasons. However, there may be sound reasons to lower that percentage or even disable it completely (non-root partition, data-only storage, huge files, ext4 etc.).

Let me quote Linux filesystem guru Ted Ts’o on this:

If you set the reserved block count to zero, it won’t affect performance much except if you run for long periods of time (with lots of file creates and deletes) while the filesystem is almost full (i.e., say above 95%), at which point you’ll be subject to fragmentation problems. Ext4′s multi-block allocator is much more fragmentation resistant, because it tries much harder to find contiguous blocks, so even if you don’t enable the other ext4 features, you’ll see better results simply mounting an ext3 filesystem using ext4 before the filesystem gets completely full.

If you are just using the filesystem for long-term archive, where files aren’t changing very often (i.e., a huge mp3 or video store), it obviously won’t matter.

You can change the reserved block percentage by invoking

tune2fs -m 1 /dev/sdb1

or disable it completely:

tune2fs -m 0 /dev/sdb1

To check, how many block are reserved on a given filesystem, run

tune2fs -l /dev/sdb1 | grep "Reserved block count"

Of course, you have to adjust /dev/sdb1 to your needs.

Resources:
http://unix.stackexchange.com/questions/7950/reserved-space-for-root-on-a-filesystem-why
See also tune2fs manpage