Slashdot Mirror
File Fragmentation and File System Resiliency
Eric^2 asks: "We have an old NT server that we are going to replace sometime this year. It has Diskeeper on it to do disk defragmentation. I remember from DOS that this was also a BIG problem, and am curious how the EXT2FS handles file fragmentation. Whatever we put in to replace that NT box needs to be fairly resiliant, and I was thinking either FreeBSD, or maybe Linux with the XFS file system, as it's supposed to be more fault tolerant. I would appreciate any suggestions that you may have! Is there a more robust solution than XFS for Linux? FreeBSD? Should I stick with NT and Diskeeper? "
EXT2FS does not have much problem with file fragmentation. Like most Unix filesystems, it automatically reuses all empty space and tries to keep files/directories together.
XFS does look interesting, and it should at least reduce restart time.
Notice that on a server you can reduce file system updates by putting files which are rarely updated on read-only filesystems which are separate from the often-updated ones, reducing the partitions which need to be checked.
Of course, maybe you should also start by considering how much better anything else is when compared to what you're presently using. NT needs defragmentation, and crashes often enough that restart time and disk recovery are great concerns.
If you are talking about running Linux with XFS - you aren't ready to run Linux. XFS is not in the Linux kernel. Before you consider switching away from NT, gain some admin time on a FreeBSD and/or Linux box, and see how they work. Work with Samba and see how the combo meets your needs and if you are up to admining the system. If so, you may want to look at ext3 or reiserfs (journaling filesystems) that should be more robust than ext2.
I have never had data loss with linux unless it was me inadvertently deleting something. I loose my machine to power outages at least once a month, and once when netscape was open it came back with an empty bookmarks file, but the whole bookmarks file was in /lost+found. I also regularly start huge compile runs on my laptop, put it in my backpack, and let it compile until the battery runs out. When I plug it in it fsck's on the way up, but I just restart the compile and it is fine. So I don't have your experience of loosing data on a power outage.
I recently bought a cheap big IDE drive for my home machine. I plan to have a couple of partitions for experimenting with ext3 and other journaling filesystems. But I don't really ever stress the ext2 filesystem, so all I can test is that it is as good as ext2. How would you test a filesytem for reliability and crash resistence ?
Another question: I have noticed that access from linux to a FAT32 partition is much slower than from windows to a FAT32 partion. Linux FAT32 access is also much slower than Linux ext2 access. I would expect some difference -- who wants to spend a lot of time making the FAT32 fs code fast -- but the difference seems rediculous, at least 2 times slower. Why is this ?
If you have problems with ext2 you might want to look at some of the links posted here:
2 .shtml
http://slashdot.org/askslashdot/00/01/22/195821
Why is the root of this thread marked offtopic ? I'll have to start meta-moderating more regularly.