I've reinstalled hardy 4 times over the past 2 months due to the EXT3
filesystem getting corrupted. I didn't have any such problem on gutsy, just hardy. I'm just running a desktop, but using crypto and lvm to put both the root and swap within the same partition, with a separate small /boot partition. All done from the alternate installer. So, after 3 installs with EXT3, I decided to try something else. I notice the installer offers JFS, XFS, and ReiserFS, so I picked JFS for the 4th reinstall. I've been running it a couple days and have purposely crashed the system at least 10 times and not yet had any filesystem problem. This makes me believe there is some bug in the EXT3 driver rather than a hardware problem on my harddrive. I have a Seagate Technologies harddrive. I also noticed some bugs on launchpad about similar experiences with EXT3, but no solutions. I read some on wikipedia and googling, but I couldn't get anything more than specifications .. nothing on performance comparisons among the 4. Anyone know any reason to avoid JFS or use any other? TIA, -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
Paul S wrote:
> Anyone know any reason to avoid JFS or use any other? No. I've been happily using JFS for years now (since running into frequent problems with corruption with Reiser). -- derek -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
In reply to this post by Bugzilla from paulatgm@gmail.com
Paul S wrote:
> I've reinstalled hardy 4 times over the past 2 months due to the EXT3 > filesystem getting corrupted. I didn't have any such problem on gutsy, > just hardy. > > I'm just running a desktop, but using crypto and lvm to put both the > root and swap within the same partition, with a separate small /boot > partition. All done from the alternate installer. > > So, after 3 installs with EXT3, I decided to try something else. I > notice the installer offers JFS, XFS, and ReiserFS, so I picked JFS for > the 4th reinstall. > > I've been running it a couple days and have purposely crashed the system > at least 10 times and not yet had any filesystem problem. This makes me > believe there is some bug in the EXT3 driver rather than a hardware > problem on my harddrive. I have a Seagate Technologies harddrive. > > I also noticed some bugs on launchpad about similar experiences with > EXT3, but no solutions. > > I read some on wikipedia and googling, but I couldn't get anything more > than specifications .. nothing on performance comparisons among the 4. > > Anyone know any reason to avoid JFS or use any other? > > TIA, > > while having problems with nVidia I had to just turn off the computer many times. It came back up with small errors corrected while 7.10 booted up. Are you saying Hardy will not correct the small errors, or that the errors are large and cannot be corrected? Karl -- Karl F. Larsen, AKA K5DI Linux User #450462 http://counter.li.org. PGP 4208 4D6E 595F 22B9 FF1C ECB6 4A3C 2C54 FE23 53A7 -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
In reply to this post by Bugzilla from paulatgm@gmail.com
On Mon 28 Apr 2008 21:55:40 Paul S wrote:
> > Anyone know any reason to avoid JFS or use any other? My very limited experience on different FS's is as follows: If you intend to use LVM (which I use both at work, at home, and every family/friends computer I put my hands and ubuntu on), the FS you choose is an important choice, when it comes the time to resize it. IIRC the LVM howto states that ext3 and reiserf need to be unmounted to be resized, while JFS and XFS don't. The two latter also don't support shrinking, which IIRC is supported by the first two (but it's been a while since I read about this, and it could have changed). If you are sure of your partition scheme, after you add another hard disk, JFS or XFS will allow you to add the HD to the volume group on the fly (cool, huh?). On the minus site, ext3 doesn't allow you to recover deleted files (ext2, while I've been *told* this can be done in reiserfs (never tried it though). I've no information on this for JFS or XFS. About speed, reiserfs is largely claimed to be faster if you deal with many (several thousands) small (few kbs) files, and JFS is claimed to be the fastest overall. I tried JFS with edgy and Feisty, and to be honest, I didn't notice a difference (but I didn't make any objective measurements). Just before the Gutsy cycle, I started working in the situation where reiserfs is considered best (thousands of small data files), so I changed to reiserfs in gutsy, and have been using it so far. I've *never* had any particular trouble with corruption with either or ext3, jfs or reiserfs, that was not caused by power failure or bad HD, and for a while when I had reiser at work and jfs at home, I had an annoyance about EA (extended attributes) on files I backed up to get the two boxes in sync daily (I use dar on a USB key for this), but it was not more than annoying warning messages, and no corruption was ever done (as confirmed by rsync and diff several times). All in all, in my limited experience, for a regular home user, any filesystem will do just nice. regards FF -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
In reply to this post by Bugzilla from paulatgm@gmail.com
Paul S wrote:
> I've reinstalled hardy 4 times over the past 2 months due to the EXT3 > filesystem getting corrupted. I didn't have any such problem on gutsy, > just hardy. > > I'm just running a desktop, but using crypto and lvm to put both the > root and swap within the same partition, with a separate small /boot > partition. All done from the alternate installer. > > So, after 3 installs with EXT3, I decided to try something else. I > notice the installer offers JFS, XFS, and ReiserFS, so I picked JFS for > the 4th reinstall. > > I've been running it a couple days and have purposely crashed the system > at least 10 times and not yet had any filesystem problem. This makes me > believe there is some bug in the EXT3 driver rather than a hardware > problem on my harddrive. I have a Seagate Technologies harddrive. > > I also noticed some bugs on launchpad about similar experiences with > EXT3, but no solutions. > > I read some on wikipedia and googling, but I couldn't get anything more > than specifications .. nothing on performance comparisons among the 4. > > Anyone know any reason to avoid JFS or use any other? > > TIA, > I can't comment on your EXT3 problems.. In my experience, EXT3 has been the most stable and easy to recover file system (and I have stress tested all of them several times.) That being said, I'll share my observations so far on the others. I've had several minor corruption problems with JFS on at least 3 distros over several kernel versions. It was nothing jfsrepair couldn't fix, but since is it was meta data corruption caused in unclean shutdowns, they really shouldn't happen at all in a journaled file system. I don't think JFS journaling is very robust. I've also encountered lots of strange performance bottlenecks with JFS. Even though if I create an artificial test, (with file system benchmarks, or my own favorite, working with 2+GB Maildir spools) it surpasses all others. But in real world use, some strange combinations end up causing it to go slow.... sometimes the speed problems were even induced by filenames! (for example,, if I untarred a file that contained multiple 2 gig files with .aa .ab .ac etc extensions, the untarring would slow to a crawl.. if Instead I packed the files without the same extensions, the problem would not occur). The biggest problem with JFS, IMO, is that it's simply not used enough to get the kind of natural testing the other FS's do.. for example, last year at some point, quotas were completely broken by a kernel update, but no one even noticed for 3 point releases of the kernel! ReiserFS is supposed to be the fastest with small files. I call poppycock on that one.. ReiserFS is only fast in Namesys benchmarks. The problem with reiser is that readdir operations don't return the filenames in the same order they were written to disk (inode order). So if you pack thousands of small files into a directory, then try to back them up with tar, or copy them, or search through them for a string, your IO throughput drops to nearly 0 while the hard drive furiously seeks randomly across the whole platter for each and every file. JFS and XFS don't have this problem, and were much faster for hosting large directories of small files (the Maildir test.) Even if Reiser is superior for some tasks, I wouldn't count on it being well maintained going forward into the future. Suse, once Reiser's largest supporter, even switched away from the file system for this reason. And given today's news, I don't expect this file system to gather more support going forward. XFS, performance wise, is probably the all around best file system. I had no problems with XFS file system corruption, or performance on any kind of workload (be it the maildir test or hosting 100's of GB in DVD rips.) Unfortunately, XFS has a critical flaw (err, sorry, I mean feature, if you ask the XFS devs) that makes it unsuitable for general purpose File system. Unlike all other filesystem candidates, the meta data is not written to disk in an ordered fashion. In the case of an unclean shutdown, XFS will pad the difference with Null byte characters. For example, lets say you are writing a 1kb file. 500 bytes got flushed to disk before the system was interrupted, but the journal was already updated with the 1kb filesize. When you reboot, you'll have a 1kb file, containing 500 bytes of data and 500 bytes of null. For the love of all that is holy, *never* use XFS to hold something like an FTP mirror. Most mirror scripts check file datestamp and filesize, but will not be able to detect files trashed by XFS unless you do an md5sum check on the whole thing. EXT3, as I said, worked well for me in all generic circumstances. In a default filesystem, however, you will run into trouble if you try to stuff thousands of files in 1 directory. Your file system will be in pain after 2000 files, almost unusable after 50000. You can fix this by adding the dir_index option, after which EXT3 will perform more or less the same as ReiserFS. -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
In reply to this post by Karl Larsen
Karl Larsen said the following on 04/29/2008 08:09 AM:
> Paul S wrote: >> I've reinstalled hardy 4 times over the past 2 months due to the EXT3 >> filesystem getting corrupted. I didn't have any such problem on gutsy, >> just hardy. > How do you know it is the file system is bad? I am using EXT3 and > while having problems with nVidia I had to just turn off the computer > many times. It came back up with small errors corrected while 7.10 > booted up. > > Are you saying Hardy will not correct the small errors, or that the > errors are large and cannot be corrected? Specifically, after a normal shutdown (no power failure or anything), when I next booted the fsck kicked in because of some irregularity that fsck detected. The automatic fsck failed with the error message that it had to be done manually in read only mode. So, I did it manually and replied Y to each prompt that came up. I'm not a ext3 fsck expert, so didn't understand the messages and prompts of fsck. After all were corrected, I rebooted. Once the desktop launched, I had a screen showing only the wallpaper and an empty panel .. and no response to any key or mouse inputs. So, it some vital files were ruined by the fsck. This happened 3 times previously on earlier versions of hardy, all on ext3. I also have a second partition where I was doing some xorg driver testing on hardy. That partition is also ext3. It is not encrypted nor is it LVM, but just regular. The last time I booted it, I got the same fsck error messages. I have not had time to go back to run it and see if it's also ruined. So far, using JFS on this reinstall, no such problems ... that's what makes me think it's software not hardware. regards, -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
In reply to this post by Rashkae-2
Rashkae said the following on 04/29/2008 01:02 PM:
> I can't comment on your EXT3 problems.. In my experience, EXT3 has been > the most stable and easy to recover file system (and I have stress > tested all of them several times.) That being said, I'll share my > observations so far on the others. I've never had a problem before hardy either with ext3 being corrupted to be unusable. Thanks for your comments on the others. regards, -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
Paul S wrote:
> Rashkae said the following on 04/29/2008 01:02 PM: > >> I can't comment on your EXT3 problems.. In my experience, EXT3 has been >> the most stable and easy to recover file system (and I have stress >> tested all of them several times.) That being said, I'll share my >> observations so far on the others. >> > > I've never had a problem before hardy either with ext3 being corrupted > to be unusable. > > Thanks for your comments on the others. > > regards, > > with a ext3 partition. I use the the same Home partition on 7.10 and Hardy. When I boot Hardy it finds this Home partition as flawed. But it was just working fine on 7.10. I have to let it "fix" the partition to use it. I go back and there is no problem. Karl -- Karl F. Larsen, AKA K5DI Linux User #450462 http://counter.li.org. PGP 4208 4D6E 595F 22B9 FF1C ECB6 4A3C 2C54 FE23 53A7 -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
Karl Larsen said the following on 04/29/2008 03:06 PM:
> Thinking about this I do have experience with Hardy finding fault > with a ext3 partition. I use the the same Home partition on 7.10 and > Hardy. When I boot Hardy it finds this Home partition as flawed. But it > was just working fine on 7.10. I have to let it "fix" the partition to > use it. I go back and there is no problem. OK, I had that several times too. On some occasions fsck did not destroy any important files. But, when it finally did, then I had to reinstall. Your experience adds to my idea that something is different in hardy. regards, -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
In reply to this post by Rashkae-2
On Tue 29 Apr 2008 20:00:06 Res wrote:
> So basically reiser is good for stuff like maildir mail > spools, and probably anything else, the only thing I wouldnt run on > reiserfs, is databases, because I want rock hard reliance, I want run > any > journalled FS, so its ext2 only for MySQL's data dir. Eh, since reiserfs is journaled it should give you the reliance you asked for, if journaling is your parameter. Also, ext2 is not. regards FF -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
In reply to this post by Bugzilla from philsf79@gmail.com
Em Terça 29 Abril 2008, Felipe Figueiredo escreveu:
> If you intend to use LVM (which I use both at work, at home, and > every family/friends computer I put my hands and ubuntu on), the > FS you choose is an important choice, when it comes the time to > resize it. IIRC the LVM howto states that ext3 and reiserf need > to be unmounted to be resized, To be exact, ext2/3 and reiserfs only need to be unmounted if you want to shrink it. Both grow on the fly, just like jfs and xfs. -- Alvaro Figueiredo [hidden email] -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
In reply to this post by Bugzilla from philsf79@gmail.com
Felipe Figueiredo wrote:
> On Tue 29 Apr 2008 20:00:06 Res wrote: > > >> So basically reiser is good for stuff like maildir mail >> spools, and probably anything else, the only thing I wouldnt run on >> reiserfs, is databases, because I want rock hard reliance, I want run >> any >> journalled FS, so its ext2 only for MySQL's data dir. > > Eh, since reiserfs is journaled it should give you the reliance you asked > for, if journaling is your parameter. Also, ext2 is not. I _think_ he said he "won't" run a journalled FS because it's unreliable. That's just plain wrong. It _may_ not be necessary to put a MySQL database on a journalled filesystem, because good relational databases do their own journalling (I _don't_ know if that's true of MySQL). -- derek -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
In reply to this post by Rashkae-2
Res wrote:
> On Tue, 29 Apr 2008, Rashkae wrote: > >> ReiserFS is supposed to be the fastest with small files. I call >> poppycock on that one.. ReiserFS is only fast in Namesys benchmarks. > > > We have a mailstore, using vpopmail so its maildir, we did comparison > tests between ext2, ext3 and reiserfs, the same data, as the test box > grabbed the mail from our nightly rsync backup and sent it to and > from another dummy server, so we knew it would always be the same data, > ext2 and ext3 performed the same speedwise, ext3 recovered faster for > obvious reasons from a deliberate hard power-off, the rsync for ext2 and 3 > took around 1 hour 40mins, for reiserfs the rsync from took 18 mins, and > send, it took about 1 hour 25 mins, so it has marginal write performance > but huge read performances, > Your test case in this instance is a bit of a fluke... The read performance for Reiser (and ext3 with dir_index option) is *very* dependent on the order the files were written in. If the files get written to the disk in the same order as the file system hash algorithm would produce, you get full speed read performance on either system... Here's an example... configure mutt to store mail in a maidir location. then use mutt to copy gigantic quantities of messages into the mail store. You need to copy enough mail that reading the entire directory will exhaust your file cache. You may want to reduce ram for this test. Once all the mail is written, close mutt. Now try to use tar to create a backup of the maidir folder. You should notice a very slow filesystem IO, somewhere in the area of 1 to 2 MiB/s. Once the backup is complete, delete the maildir, then restore it from your tar file. Create a tar backup again... This time, your file IO should be well over 20 MiB/S. The reason is that the first time, tar stored the files in the same order as the file system hash order, and when the tar file was restored, the files got written to disk in that same order as well. This performance boost will quickly degrade once you start using the system however. XFS and JFS don't suffer near the same performance penalties and will maintain read performance for the entire directory over time. -- ubuntu-users mailing list [hidden email] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users |
Free forum by Nabble | Edit this page |