Best FS for Slackware

bret381 · 12-05-2009, 07:24 AM

read up and decide for yourself

http://www.debian-administration.org/articles/388

Didier Spaier · 12-05-2009, 07:24 AM

See http://kernel.org/faq/#howdoesitwork

If what's good for Linus is good for Alex, then try XFS

Caveat : but you can't shrink it directly, see http://xfs.org/index.php/XFS_FAQ and http://gparted.sourceforge.net/features.php

[EDIT] And you can't install LILO on a (XFS) root partition, only on the MBR. That'd be a problem for me as I want to preserve my Windows' boot loader (yes, I do launch it every now and then) on my Lenovo Thinkpad T61 (thus /dev/sda4 being my root Linux partition I have "boot = /dev/sda4" in lilo.conf and I made /dev/sda4 bootable).

~sHyLoCk~ · 12-05-2009, 07:46 AM

Quote:

Originally Posted by bret381

read up and decide for yourself

http://www.debian-administration.org/articles/388

Very old link though, does anyone have any recent benchmarks? I found one of osnews but that was of 2007. :\

H_TeXMeX_H · 12-05-2009, 08:51 AM

One note:

If you choose JFS make sure to read:
http://wiki.archlinux.org/index.php/JFS_Filesystem

it mentions several important things.

Rupa · 12-05-2009, 11:15 AM

Quote:

Originally Posted by gargamel

I have to say, I had JFS on my external USB 1TB device, but I had problems with the partition table after LUKS encrypting it. But I don't know, if the problems were caused by the file system or by something else...

Does anyone have experience with JFS and LUKS encryption on external USB devices? Does it work? It should, but see above...

Yes, I do it a lot, have several LUKS encrypted JFS formatted USB disks. There is nothing special to do or to tell about. Just have a look at ftp://ftp.slackware.com/pub/slackwar...ADME_CRYPT.TXT

gargamel · 12-05-2009, 01:12 PM

Thanks, I'll try it out another time, then.

gargamel

guanx · 12-05-2009, 02:34 PM

Quote:

Originally Posted by H_TeXMeX_H

See:
http://www.linux-magazine.com/Online...-Ext3-and-Ext4

and much more was posted on the topic a while ago here on LQ, just search for it. I don't think anything was done about it except to maybe warn users.

Either way, if you want a thoroughly tested fs, choose ext3. If you want performance and also reasonably good reliability (but not quite as extensively tested) choose XFS or JFS.

The "problem" you quoted does not exist. The delay time can be tuned. It's not specific to either filesystem. The most possible reason why you tune the write delay is switching between battery and mains (laptop users).

BTW, in recent kernels, the default mount options of ext3 also changed to more dangerous values to improve performance.

onebuck · 12-05-2009, 02:53 PM

Hi,

Quote:

Originally Posted by guanx

The "problem" you quoted does not exist. The delay time can be tuned. It's not specific to either filesystem. The most possible reason why you tune the write delay is switching between battery and mains (laptop users).

BTW, in recent kernels, the default mount options of ext3 also changed to more dangerous values to improve performance.

Please expand on your solution other than to make an arbitrary or just plain ambiguous statement. I've yet to experience problems with ext3 and I am curious where your getting the information.

Ilgar · 12-05-2009, 05:22 PM

Quote:

Originally Posted by guanx

The "problem" you quoted does not exist. The delay time can be tuned. It's not specific to either filesystem.

There was a long thread (titled like "slow application startup" or something) where this issue about ext3 came up. There was a kernel bug known as the Linux I/O wait bug, there were long discussions on the kernel bugzilla page. In the end it was closed as unresolved, since there appeared to be multiple factors causing high wait times. Some of these were filesystem-independent, likely to be related to the scheduler, but there was disagreement over whether it was a bug or just the expected behaviour under load. I don't know if they did any changes to the scheduler code about this. If what you're referring to above is this part of the problem, afaik you can't tune the delay time (unless you tinker with the kernel maybe?).

However there were also cases that were tracked down to the ext3 code (more specifically, to the way data=ordered mode behaves). There were so many complaints that they ended up switching the default mount option to data=writeback in ext3 and ext4. This is the unsafe choice, even Torvalds was openly against the idea. There were reported cases of data loss, too. I think they did little improvements to reduce the risk. Some Ext4 developers even said "it's not a bug, it's a feature" and blamed on poorly written application codes for not doing necessary checks and assuming certain behaviour. Anyway, writeback is still considered the unsafe default. As I said above they were working on an intermediate solution but I haven't followed up on that.

jjthomas · 12-05-2009, 10:07 PM

I've been happy with JFS. I use ext2 for my boot partition; ext3 or JFS for the remainder partitions. With Slackware I use JFS; with debian and CentOS I use ext3.

I had two crashes running Ubuntu on ext4 partitions. I was not able to do any recovery after the crashes. One of the machine would not even boot.

See http://www.h-online.com/open/news/it...t4-740467.html
and https://bugs.edge.launchpad.net/ubun...81/comments/45
about the 7th paragraph down where it talks about delayed allocation.

-JJ

BrZ · 12-06-2009, 10:48 AM

I'm using ext4 with 'noatime,barrier=0,data=writeback,nobh,commit=100'. It's being solid until now, but my backups are synced every night ;]

The other machine is working for years with Reiser and abused really hard without problems. I'm just waiting my vacation to format one old spare rig and install Slack with JFS and satisfy an old desire to try this fs.