LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 09-03-2012, 01:06 PM   #31
gezley
Member
 
Registered: Sep 2009
Location: Ireland
Distribution: Slackware64, NetBSD
Posts: 495

Rep: Reputation: 207Reputation: 207Reputation: 207

Quote:
Originally Posted by nass View Post
What you say is interesting about XFS being updated in the kernel v3.x.xx.
Because it used to be unbearably slow at massive delete operations. see here.
Something like the following in /etc/fstab might help to speed up read-write-delete in directories with many subdirectories and/or many files - especially small files:

Code:
/dev/sda7	/home	xfs defaults,noatime,logbsize=256k,logbufs=8 0 0
Quote:
Originally Posted by nass View Post
Also XFS seems like a bad choice for laptops due to its delayed write operations (i actuall have lost data due to battery going out).

Are these things fixed now?
I once read that a filesystem should not be blamed for loss of data. It is the job of a filesystem and its associated utilities to make sure it comes back online in a consistent state after something like a power cut, not to restore data. That is what backups are for, and thus, this is not a problem that needs to be "fixed" in the filesystem. All I can tell you is that XFS has not let me down once, and I've had several unexpected power cuts. But XFS and JFS were designed as server filesystems from the outset, so perhaps that will guide your thinking when it comes to using one or the other on a laptop.

Last edited by gezley; 09-03-2012 at 01:08 PM.
 
Old 09-03-2012, 02:57 PM   #32
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,252

Rep: Reputation: 630Reputation: 630Reputation: 630Reputation: 630Reputation: 630Reputation: 630
For a completely anecdotal comparison, my server uses XFS and I did not lose data despite a partial hardware failure of the hard drive (which had to be replaced, but I was able to copy the data off of it). Meanwhile, a regular power-out recently corrupted my /usr partition on my desktop's ext4 filesystem. Both are good filesystems and have different strengths, but I'm not sure there is any good data about filesystem failure probability, since it is hard to measure (and there is anecdotal evidence favouring every filesystem from someone). I have no plans to stray from ext4 on my desktop, nor to stray from XFS on my server (with the possible exception of btrfs if it becomes a little more mature).
 
Old 09-03-2012, 04:07 PM   #33
GazL
Senior Member
 
Registered: May 2008
Posts: 3,380

Rep: Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912
I have all my CD's ripped to a directory in a /Artist/album layout. Doing a ls -d */* to get a list of all the albums across all artists was taking around 4 seconds on JFS. Doing the same operation on ext4 took approx half a second. I also noticed that things such as git operations were very much slower on jfs too. Once things were in the filesystem cache things were more equal but jfs was still slower.

I've always known that jfs file creation/deletion was slower because of the dynamic inode structure it uses, but I hadn't appreciated that it also affects directory traversal/metadata reads quite so badly. Anyway, I've switched back to ext4 now, though I was very tempted to try out xfs.


Just had a pretty nasty electricity brown-out tonight. Everything looks intact, but in these situations I think it's more a case of luck than anything else. When power fades in and out like that it's anyone's guess what will happen at the disk heads.
 
Old 09-03-2012, 07:13 PM   #34
damgar
Senior Member
 
Registered: Sep 2009
Location: dallas, tx
Distribution: Slackware - current multilib/gsb Arch
Posts: 1,949
Blog Entries: 8

Original Poster
Rep: Reputation: 201Reputation: 201Reputation: 201
Quote:
Originally Posted by GazL View Post
I have all my CD's ripped to a directory in a /Artist/album layout. Doing a ls -d */* to get a list of all the albums across all artists was taking around 4 seconds on JFS. Doing the same operation on ext4 took approx half a second. I also noticed that things such as git operations were very much slower on jfs too. Once things were in the filesystem cache things were more equal but jfs was still slower.

I've always known that jfs file creation/deletion was slower because of the dynamic inode structure it uses, but I hadn't appreciated that it also affects directory traversal/metadata reads quite so badly. Anyway, I've switched back to ext4 now, though I was very tempted to try out xfs.


Just had a pretty nasty electricity brown-out tonight. Everything looks intact, but in these situations I think it's more a case of luck than anything else. When power fades in and out like that it's anyone's guess what will happen at the disk heads.
Oh boy, yesterday while copying almost 200GB worth of music from my previous machine to my new (xfs) machine we were experiencing a brownout where the tv wouldn't even stay on followed by a 5 hour outage. The culprit was a transformer that failed which in turn burnt down one of the overhead lines causing another transformer to fail. I didn't realize the electrical issue until after the copy had completed (4.5 hours!). Right now I'm md5'ing both directories. On the bright side it's my first test of xfs and the power seems steady for the first time in almost two years since the new transformers were installed!
 
Old 09-04-2012, 01:22 PM   #35
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
Quote:
Originally Posted by GazL View Post
I have all my CD's ripped to a directory in a /Artist/album layout. Doing a ls -d */* to get a list of all the albums across all artists was taking around 4 seconds on JFS. Doing the same operation on ext4 took approx half a second. I also noticed that things such as git operations were very much slower on jfs too. Once things were in the filesystem cache things were more equal but jfs was still slower.

I've always known that jfs file creation/deletion was slower because of the dynamic inode structure it uses, but I hadn't appreciated that it also affects directory traversal/metadata reads quite so badly. Anyway, I've switched back to ext4 now, though I was very tempted to try out xfs.


Just had a pretty nasty electricity brown-out tonight. Everything looks intact, but in these situations I think it's more a case of luck than anything else. When power fades in and out like that it's anyone's guess what will happen at the disk heads.
Deleting files on JFS is instantaneous.
Here's my benchmark of more recent filesystems:
http://www.linuxquestions.org/questi...k-data-900888/

Certain options like data=writeback on ext4 will make data loss more likely. Any filesystem that caches data to RAM for extended periods is more susceptible.
 
Old 09-04-2012, 03:12 PM   #36
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,817

Rep: Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817
Quite an interesting presentation on recent XFS improvements that are now available in recent kernels:

http://www.youtube.com/watch?v=FegjLbCnoBw
 
1 members found this post helpful.
Old 09-05-2012, 03:09 AM   #37
Slackovado
Member
 
Registered: Mar 2005
Location: Burnaby, BC, Canada
Distribution: Slackware 14 32bit, Debian, Arch
Posts: 213

Rep: Reputation: 27
Quote:
Originally Posted by H_TeXMeX_H View Post
Deleting files on JFS is instantaneous.
Here's my benchmark of more recent filesystems:
http://www.linuxquestions.org/questi...k-data-900888/

Certain options like data=writeback on ext4 will make data loss more likely. Any filesystem that caches data to RAM for extended periods is more susceptible.
As big a fan of XFS as I'm, I have to say that deleting files is slow when filesystem is more than 90% full.
However, my "home" filesystem is over 5 years old, and I've had at least 20 power outages at this place. But everything is still fine. No file corruption at all.

Last edited by Slackovado; 09-06-2012 at 11:31 AM. Reason: Correct spelling
 
Old 09-05-2012, 03:40 AM   #38
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,817

Rep: Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817Reputation: 817
@H_TeXMeX_H: What kernel were you running in your benchmarks? The stock 2.6.37.6 from 13.37? If so the XFS improvements that fix the major performance bottlenecks are not found until 2.6.39 and up. Phoronix found that in some benchmarks like PostMark v1.5.1 Disk Transaction Performance, XFS had a 6.4x performance improvement in modern kernels. I'd be very interested to see how XFS performs in Slackware 14.0. I suspect it will perform a lot better.
 
Old 09-05-2012, 06:57 AM   #39
D1ver
Member
 
Registered: Jan 2010
Distribution: Slackware 13.37
Posts: 527
Blog Entries: 3

Rep: Reputation: 126Reputation: 126
Interesting video. I have let my curiosity get the better of me and reinstalled slackware 14 on this new laptop of mine.

XFS on a 120 gig root partition on an ssd. Mounted with "defaults,noatime,discard". Everything seems to be working pretty well
 
Old 09-05-2012, 08:28 AM   #40
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
Quote:
Originally Posted by ruario View Post
@H_TeXMeX_H: What kernel were you running in your benchmarks? The stock 2.6.37.6 from 13.37? If so the XFS improvements that fix the major performance bottlenecks are not found until 2.6.39 and up. Phoronix found that in some benchmarks like PostMark v1.5.1 Disk Transaction Performance, XFS had a 6.4x performance improvement in modern kernels. I'd be very interested to see how XFS performs in Slackware 14.0. I suspect it will perform a lot better.
Yeah, it is the stock kernel. I will test it in slackware 14.0 as well.
 
Old 09-05-2012, 08:44 AM   #41
gezley
Member
 
Registered: Sep 2009
Location: Ireland
Distribution: Slackware64, NetBSD
Posts: 495

Rep: Reputation: 207Reputation: 207Reputation: 207
Quote:
Originally Posted by D1ver View Post
Interesting video. I have let my curiosity get the better of me and reinstalled slackware 14 on this new laptop of mine.

XFS on a 120 gig root partition on an ssd. Mounted with "defaults,noatime,discard". Everything seems to be working pretty well
Other readers should bear in mind that LILO must be installed to the MBR if they format their root partition with XFS. LILO will not boot if it is installed to a XFS-formatted root partition. (They can of course create a small ext3 /boot partition and install LILO there instead.)

More here.
 
Old 09-05-2012, 09:35 AM   #42
FeyFre
Member
 
Registered: Jun 2010
Location: Ukraine, Vinnitsa
Distribution: Slackware
Posts: 307

Rep: Reputation: 22
Using raiser where system is isolated, and ext3 if MS Windows is neighbour(did not meat any normal developer who wishes to port raiserfs driver to windows, only dumbs).
 
Old 09-09-2012, 03:50 PM   #43
Martinus2u
Member
 
Registered: Apr 2010
Distribution: Slackware
Posts: 345

Rep: Reputation: 56
Sorry for reviving this thread, i've only just returned from a holiday.

Quote:
Originally Posted by gezley View Post
It is the job of a filesystem and its associated utilities to make sure it comes back online in a consistent state after something like a power cut, not to restore data.
This statement is so true. "Consistent", btw, means: not only does fsck succeed, but the file content doesn't change silently. Which in turn is the reason why mount flags like data=writeback and nobarrier for ext4 are ludicrous: consistent data is not guaranteed. Even worse: depending on writeback parameters, an inconcistent state is present on disk over prolonged periods of time, just waiting for an accident to happen.

As konsolebox pointed out earlier: if you know what you're doing and if you have measures in place to deal with the unspeakable, go for it. Everybody else, stay away.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Kernel Log: Coming in 2.6.39 (Part 2) Storage and file systems LXer Syndicated Linux News 0 04-27-2011 06:30 AM
LXer: Kernel Log: Coming in 2.6.38 (Part 2) File systems LXer Syndicated Linux News 0 02-18-2011 04:30 PM
LXer: Kernel Log: Coming in 2.6.37 (Part 2) - File systems LXer Syndicated Linux News 0 12-09-2010 03:10 PM
LXer: Kernel Log: Coming in 2.6.34 (Part 2) - File Systems LXer Syndicated Linux News 0 04-23-2010 04:21 PM
LXer: Kernel Log: What's coming in 2.6.30 - File systems: New and revamped file syste LXer Syndicated Linux News 0 04-27-2009 11:02 PM


All times are GMT -5. The time now is 04:46 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration