Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Re:Happy with XFS (Score 4, Informative) 268

by Booker (#43559007) Attached to: Btrfs Is Getting There, But Not Quite Ready For Production

So, until your understand this basic idea, don't go claiming you know _ANYTHING_ about filesystems.

Without sounding like too much of a jerk, I have hundreds of commits in the linux-2.6 fs/* tree. This is what I do for a living.
I actually do have a pretty decent grasp of how Linux journaling filesystems behave. :)

Test your assumptions on ext4 with default mount options. Create a new file and write some buffered data to it, wait 5-10 seconds, punch the power button, and see what you get. (You'll get a 0 length file) Or write a pattern to a file, sync it, overwrite with a new pattern, and punch power. (You'll get the old pattern). Or write data to a file, sync it, extend it, and punch power. (You'll get the pre-extension size). Wait until the kernel pushes data out of the page cache to disk, *then* punch power, and you'll get everything you wrote, obviously.

XFS and ext4 behave identically in all these scenarios. Maybe you can show me a testcase where XFS misbehaves in your opinion? (bonus points for demonstrating where XFS actually fails any posix guarantee).

Yes, ext3/4 have data=journaled - but its not default, and with ext4, that option disables delalloc and O_DIRECT capabilities. 99% of the world doesn't run that way; it's slower for almost all workloads and TBH, is only lightly tested.

Yes, ext3's data=ordered pushes out tons of file data on every journal commit. That has serious performance implications, but it does shorten the window for buffered data loss to the journal commit time.

You want data persistence with a posix filesystem? Use the proper data integrity syscalls, that's all there is to it.

Comment: Re:Happy with XFS (Score 4, Informative) 268

by Booker (#43556015) Attached to: Btrfs Is Getting There, But Not Quite Ready For Production

No, that's FUD and/or misunderstanding on your part.

"data=ordered" is ext3/4's name for "don't expose stale data on a crash," something which XFS has never done, with or without a mount option. ext3/4 also have "data=writeback" which means "DO expose stale data on a crash." XFS does not need feature parity for ill-advised options.

Any filesystem will lose buffered and unsynced file data on a crash (http://lwn.net/Articles/457667/). XFS has made filesystem integrity and data persistence job one since before ext3 existed. Like any filesystem, it has had bugs, but implying that it was unsafe for use until recently is incorrect.

I say this as someone who's been working on ext3, ext4 and xfs code for over a decade, combined.

Comment: Maybe currentcost (Score 2, Informative) 172

by Booker (#33692840) Attached to: Real-Time Power Monitoring Options?
The currentcost meters are fairly cheap, OSX-capable I think, and very popular in Europe so there are lots of little scripts for them. In the us you can find them at http://currentcost.net/buynowmain.html

The DIY rig at http://openenegymonitor.org/ is fairly straightforward, even if you're not that technically inclined....

Otherwise I'd just echo the suggestion to suck it up for the extra $50 and get the Ted 5000

My recent time-waster is finding a way to make all these different gadgets able to talk to all the various websites ...

panic: can't find /

Working...