Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm running the recently-released Fedora 18, and doing some computationally intensive things with it. The result is... unstable, at best. But! That's about what I expected, or at least not what I'm going to complain about here.

The problem I have is with how XFS handles disk writes - slowly. I have three XFS partitions that I'm working with, and whenever the system crashes, any recently created files just go away. Poof! And I'm getting tired of downloading the same song over and over again, to say nothing of the actual useful data I'm working with. As best I can tell, this has to do with write caching.

So, I see two solutions to this. One of the most obvious, though perhaps not as reliable, would be to force the drive to make sure a file is really, truly written before it is able to be read. But perhaps a better solution, especially if I can set up a cronjob, would be to just force a write every n minutes; probably 5, I'm thinking. And obviously, if the drive hasn't been written to in the past 5 minutes, it's not under enough duress to make caching worth it!

The question is, does XFS even have an external command for forcing a write? Or maybe an option of its own?

EDIT: There a reason for that downvote? Is this something everyone knows but me? If it's so stupid, maybe someone can spell it out for me.

share|improve this question

1 Answer 1

You can't force XFS to do a write - and the problems you are seeing are unlikely to be anything related to XFS.

Most of the buffering is done at the VFS layer. You can force data to be pushed down to the next layer (XFS in this case) by executing a flush or by mounting the disk sync - however the XFS will still buffer some of the data.

Having said that, unless the entire machine is crashing, then the data has only got as far as the application's buffer - it's not in the VFS yet. But form your post that appears to be exactly what's happenning here. This seems rather surprising to me: I've found Linux to be very stable in recent years - the few system crashes I've seen have been hardware related.

The way to solve the problem is to address why your system is crashing - if it has been less stable since the last OS upgrade, then revert to something you know is stable.

how XFS handles disk writes - slowly

What is the question here? Do you just mean that there's a delay in writing stuff to disk, or that the performance is poor?

There are ways of making the filesystem more resillient (mostly at the cost of throughput) but you shouldn't begin to consider these until you've made some attempt at addressing your availabiltiy problems.

share|improve this answer
    
Well, my friend and I have been having a lot of stability issues with F18; according to her, it's always like that for the first week or two after a new release, and I certainly believe that. As for me, XFS (and only XFS) writes are being delayed indefinitely, until either a reboot or the file system has enough data to be "worth" writing. Waiting hours or even a day won't make it happen. I have magnitudes more throughput than I need on this drive; all that's important is that my data be where I put it, when I put it there, forever. –  DigitalMan Jan 18 '13 at 10:49
    
Is there a reason to assume XFS does not honour sync(2)? –  rackandboneman Jan 18 '13 at 10:49
2  
XFS (and only XFS) writes are being delayed indefinitely, until either a reboot - that's very different from your original description of the problem. Even after an explicit flush (man 1 sync)? Then you've got 3 chioces - use a different version of the OS / use a different FS / investigate the problem and log a bug report. –  symcbean Jan 18 '13 at 11:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.