Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

196 comments

linux is fail (-1, Flamebait)

Anonymous Coward | more than 2 years ago | (#38917421)

The only thing Linux does well is to suck. Use AIX, Solaris or HP-UX if you want real UNIX not kiddy shit like Linux.

Re:linux is fail (-1)

Anonymous Coward | more than 2 years ago | (#38917813)

kill yourself

Re:linux is fail (-1)

Anonymous Coward | more than 2 years ago | (#38917951)

No.

Re:linux is fail (5, Funny)

Anonymous Coward | more than 2 years ago | (#38918513)

sudo kill yourself

;-)

Re:linux is fail (1)

impaledsunset (1337701) | more than 2 years ago | (#38919519)

kill -9 $$ # does the job pretty well

Re:linux is fail (0)

Anonymous Coward | more than 2 years ago | (#38918931)

sudo dd if=/dev/zero of=/dev/brain

Re:linux is fail (2)

hobarrera (2008506) | more than 2 years ago | (#38917985)

I'll go tell _average joe/jane_ to go and get AIX, and dump ubuntu+unity which they like so much because it's shiny and pretty.

Re:linux is fail (1)

countertrolling (1585477) | more than 2 years ago | (#38918049)

Not to mention the everyday low price

Re:linux is fail (0)

Anonymous Coward | more than 2 years ago | (#38918443)

JFS also works on Linux.

Re:linux is fail (2)

hawguy (1600213) | more than 2 years ago | (#38918627)

I'll go tell _average joe/jane_ to go and get AIX, and dump ubuntu+unity which they like so much because it's shiny and pretty.

Few average Joe's have 72TB of disk space, and even for those that do, they're probably ok with 30 - 60 minutes of FSCK time. And more likely, instead of 100's of millions of files, they probably have a few million, so their fsck time will be in the 3 - 15 minute time range.

I've seen servers that take over 3 minutes for their POST check.

Re:linux is fail (1)

Anonymous Coward | more than 2 years ago | (#38919277)

Not sure how AIX will help here since it is on a similar filesystem. Also, you are comparing apples and radishes -- how does AIX compare to ubuntu+unity - one being server and other being desktop -- in other words, are you insane ?

Re:linux is fail (1)

sunderland56 (621843) | more than 2 years ago | (#38918231)

OK, so I have a large x86/64 server and want to follow your advice. Can you please tell me where you can get AIX, or HP-UX, to run on X86?

Re:linux is fail (1)

evol262 (721773) | more than 2 years ago | (#38918301)

I like how you completely ignored Solaris yet still presented the comment as if it was a valid counterargument.

Re:linux is fail (-1)

Anonymous Coward | more than 2 years ago | (#38918681)

Slowlaris! *snicker* *snicker*
Seriously, who would voluntarily use that pile of turd!?

Re:linux is fail (3, Funny)

ifrag (984323) | more than 2 years ago | (#38919069)

I like how you completely ignored Solaris yet still presented the comment as if it was a valid counterargument.

I also like how GP completely ignored Solaris. I just like the fact it is being ignored.

Re:linux is fail (0)

Anonymous Coward | more than 2 years ago | (#38919093)

He didn't type enough, zing! You really got him!

Re:linux is fail (4, Insightful)

gweihir (88907) | more than 2 years ago | (#38918467)

A cranky coward from the shadows is not s reliable source of information.

I have used AIX and Solaris, and I can say that a lot of stuff is easier on Linux.

Re:linux is fail (1)

bolthole (122186) | more than 2 years ago | (#38919059)

What "stuff"?
Give actual, useful comparisons.
Otherwise, your comment can be reduced to,
"I am most familiar with linux. Therefore, using linux is easier for me"

it's pretty bad... (0)

Anonymous Coward | more than 2 years ago | (#38917423)

NOT!
BOOYA!

fsck speed, want safety (3, Insightful)

Anonymous Coward | more than 2 years ago | (#38917439)

How fast a full fsck scan is is my last concern. What about how successful they are at recovering the filesystem?

Re:fsck speed, want safety (5, Insightful)

h4rr4r (612664) | more than 2 years ago | (#38917533)

If you need to fsck you should already be restoring from backups onto another machine.

Re:fsck speed, want safety (1, Offtopic)

ganjadude (952775) | more than 2 years ago | (#38917639)

when I need to fsck, I just call my girlfriend

Re:fsck speed, want safety (5, Funny)

darkpixel2k (623900) | more than 2 years ago | (#38918453)

when I need to fsck, I just call my girlfriend

Why? Do you not know how to use the command line?

Re:fsck speed, want safety (0, Funny)

Anonymous Coward | more than 2 years ago | (#38918543)

when I need to fsck, I just call my girlfriend

Me too.

Re:fsck speed, want safety (4, Insightful)

rickb928 (945187) | more than 2 years ago | (#38917711)

More helpful advice from the Linux community. Thank you ever so much, once again right on point, timely, and effective.

Re:fsck speed, want safety (1)

h4rr4r (612664) | more than 2 years ago | (#38917779)

No, just the truth from a real live sysadmin.

If the question had been how effective a chkdsk was I would have said the same thing.

Grow up.

Re:fsck speed, want safety (0)

Anonymous Coward | more than 2 years ago | (#38917913)

then what is the purpose of fsck and why is anyone maintaining software that are clearly not to be used ?

Re:fsck speed, want safety (3, Interesting)

h4rr4r (612664) | more than 2 years ago | (#38918073)

Because sometimes it does work. Relying on any such software is stupid.

While the FSCK/CHKDSK runs you restore onto another machine. This way if the check finishes first, you can use it until you can switch over to the restored machine. It also can save your ass if you are not smart enough/fortunate enough to have good backups.

Re:fsck speed, want safety (5, Interesting)

hackstraw (262471) | more than 2 years ago | (#38918699)

The largest filesystem I admin is just shy of 1/2 petabyte. And its one in number. Backing up everything on that filesystem is simply not feasible. To put it in perspective 1 stream @ 200 MiB/s would take almost 28 days to backup the whole thing. I would imagine a restore would take about the same order. Telling hundreds of users their files are unavailable for reading or writing for 30 days is not really an option, so I run fsck.

Backups simply are not really an option past 20+ terabytes of storage, and simply not feasible if the storage is volatile in nature. AFAIK everyone has gone to redundancy over backups at scale.

Re:fsck speed, want safety (2)

h4rr4r (612664) | more than 2 years ago | (#38918801)

You need to be writing that data to two or more, more really, filesystems at the same time. Streaming replication.

Redundancy can be backups, if they are in different locations and proper versioning is used.

Re:fsck speed, want safety (5, Insightful)

chuckymonkey (1059244) | more than 2 years ago | (#38918939)

You're fairly wrong there, you can actually back that much data up. You just have to be willing to pay for some seriously large tape libraries and they're not cheap. We're in the process of installing a 700TB array with a 1.5PB tape library backup. You just have to do the backups using filesystem snapshots and run them pretty much constantly.

Re:fsck speed, want safety (1)

Nutria (679911) | more than 2 years ago | (#38918963)

When did sys admins forget how to install multiple tape dives into a computer?

Re:fsck speed, want safety (3, Insightful)

phorm (591458) | more than 2 years ago | (#38919049)

If you're in a scenario where "Backups are not really an option", somebody is doing something wrong...

How long did it take you to get to 0.5PB? If you use a differential backup/sync, then you should generally only need to copy *NEW* data, and the old stuff will already be there.

Re:fsck speed, want safety (1)

Grishnakh (216268) | more than 2 years ago | (#38919165)

Besides the other responses to this comment, is it not possible to break up that 500TB into smaller, more manageable volumes? Does it all really need to be a single volume? Why not have a bunch of smaller volumes, each mounted to the filesystem? Then, either backing up or fscking any one volume wouldn't take that long (you could have multiple tape drives, each backing up a different volume simultaneously), and if something goes wrong with one volume the other volumes will still be ok.

Re:fsck speed, want safety (2, Interesting)

Anonymous Coward | more than 2 years ago | (#38919397)

So you have 1/2 petabyte storage but 200 MiB/s speed -- are you kidding me ? Is your storage controller broken or really cheap or both ?

Also, xfsdump (which is used to backup xfs) can do multi-threaded backups.

Now to comment on the test -- it is completely insane. As mentioned by you and others, if you are running fsck while your whole application is down -- thing broken is not system but the thing inside the skull -- you will obviously need a very fast backup/restore and/or a HA solution, both are not (and need not be) mutually exclusive.

Re:fsck speed, want safety (2)

Nutria (679911) | more than 2 years ago | (#38919073)

you restore onto another machine

ROTFLMAO,

We struggle to even get test machines; there's no way that "they" would pay for all that kit to just sit there gathering dust waiting for a disaster. If anything, it would be our DR machine and we'd instantly flip production over to it.

Re:fsck speed, want safety (0)

Anonymous Coward | more than 2 years ago | (#38918131)

I'm just guessing here but I think his point was that home users (who don't need to be very particular about data integrity anyway) don't have 70TB of storage (yet at least), those who do also got sysadmins to maintain the systems. Besides, I guess it's faster to recover from back up than actually running fsck on 70TB, 1TB is bad enough.

Re:fsck speed, want safety (0)

Anonymous Coward | more than 2 years ago | (#38918315)

Yeah that was it, more or less. I back-up my personal files, which I suspect is more than many home users do even with Linux, but that doesn't change the fact that fsck's primary purpose is to recover a potentially damaged file system. If it was to be fast, why bother at all?

Re:fsck speed, want safety (2)

h4rr4r (612664) | more than 2 years ago | (#38918365)

No, its primary job is to tell you about integrity of the filesystem. Any attempt at fixing it is secondary.

Re:fsck speed, want safety (0)

Anonymous Coward | more than 2 years ago | (#38918537)

Fair point. But speed is still lower down the list...

Re:fsck speed, want safety (2)

pankkake (877909) | more than 2 years ago | (#38918229)

Now that's just plain dishonesty.
It's not because it's not useful most of the time that it is useless or not to be used.
Some filesystems are not atomic or can be mounted with non-atomic options.
Data corruption occurs.
It's simply useful to test if the filesystem is all right. At least for developers.

Doesn't change the fact that you can't rely on fsck to *recover* data.

Re:fsck speed, want safety (0)

Anonymous Coward | more than 2 years ago | (#38919229)

Some filesystems are not atomic or can be mounted with non-atomic options.
Data corruption occurs.

That's correct.

Re:fsck speed, want safety (1)

EETech1 (1179269) | more than 2 years ago | (#38918323)

AKA the what's all the fuss about all those nines guy!

Cheers!

Re:fsck speed, want safety (0)

Anonymous Coward | more than 2 years ago | (#38919349)

So, how the fuck do you plan to resize2fs without fscking first?

Re:fsck speed, want safety (2)

pankkake (877909) | more than 2 years ago | (#38917873)

Most popular Linux filesystems are atomic and should not need fsck, unless something really bad happens.

Re:fsck speed, want safety (1)

cloudmaster (10662) | more than 2 years ago | (#38918745)

I'm also still wondering why they tested how long it takes to check a filesystem which has no problems. Why didn't they just test how long it takes to replay the journal if that's all they wanted? They wouldn't have had to wait hours for ext's fsck to finish that way. :)

Re:fsck speed, want safety (1)

Nutria (679911) | more than 2 years ago | (#38919153)

Most popular Linux filesystems are atomic and should not need fsck, unless something really bad happens.

That's a joke, right? 'Cause we *all* know that Really Bad Things *never* ever happen...

Re:fsck speed, want safety (0)

Anonymous Coward | more than 2 years ago | (#38919133)

Yes, as we all know, anonymous cowards on slashdot are the official spokesmen for the Linux community. Thanks for being rational and level headed about what you read on the internet!

Re:fsck speed, want safety (1)

Anonymous Coward | more than 2 years ago | (#38917973)

If you need to fsck you should already be restoring from backups onto another machine.

Are you retarded? Do you actually reinstall every time your box loses power? Or when a default check is initiated after X number of mounts or days since last check?

Re:fsck speed, want safety (1)

h4rr4r (612664) | more than 2 years ago | (#38918143)

I am not retarded, that is why I have an UPS and I even know how to use tune2fs.

Re:fsck speed, want safety (0)

Anonymous Coward | more than 2 years ago | (#38918331)

You are retarded if you think losing power has any incidence on a modern Linux filesystem.

Re:fsck speed, want safety (2)

HiThere (15173) | more than 2 years ago | (#38919045)

The last time I checked, the system required that fsck be run after a power loss. Also after the first reboot aften n days had passed. (I think n is somewhere around 200, but I haven't been interested enough to pin it down precisely.) And occasionally a system upgrade will require a reboot.

OTOH, recovery is definitely a lot faster than it used to be, thanks to journaling.

OTTH, all of my parftitions together are barely over 1TB, so this is only significant (to me) for future systems, when this will have changed anyway.

Restore time (0)

Anonymous Coward | more than 2 years ago | (#38918223)

"If you need to fsck you should already be restoring from backups"

You do realize how long it would take to restore 72tb on the class of hardware they were testing?

Re:Restore time (1)

h4rr4r (612664) | more than 2 years ago | (#38918341)

Seconds?

When you have that much data and you need high reliability you are doing streaming replication to multiple devices and layering other backup methods as well.

Any idea what the cost of just trusting that the FSCK fixed the problems on 72TB of data your business needs could be?

Re:fsck speed, want safety (2)

kangsterizer (1698322) | more than 2 years ago | (#38918279)

But then again, you'll want to fsck from time to time to know if you have an issue.
If you're waiting for the issue to appear "hey boss we apparently lost half the db" you'll lose more data during the time the corruption happens and you're not aware of it, than if you detected it earlier.

Thus being able to fsck in a decent amount of time matters.

Thats not the only thing of course. Sometimes you don't have a backup. Sometimes things are fucked up. Sometimes you're just required to get the thing running before the backup restoration is complete. Etc.

Otherwise, you know, we could just delete fsck, since as you pointed out, it's *never* needed!
Yea, right. :)

Re:fsck speed, want safety (1)

h4rr4r (612664) | more than 2 years ago | (#38918397)

I never said such a thing. If you are fscking you are doubting your filesystem and there fore should already be restoring your backups. If you get lucky and everything is ok all you lost was a little time, if not you are ready to roll out the machine the backups went too.

Re:fsck speed, want safety (0)

Anonymous Coward | more than 2 years ago | (#38918641)

Thus being able to fsck in a decent amount of time matters.

It sure does. If it takes more than 4 hours, call your doctor.

Re:fsck speed, want safety (1)

nine-times (778537) | more than 2 years ago | (#38918997)

Not really. First, there are problems that a filesystem check can repair without damaging the integrity of your data.

More importantly, some filesystem/disk problems are transparent until you check for errors. Linux is usually set to do a fsck at regular intervals in order to detect errors that might otherwise go undetected. So, in short, you might not know that you need to restore from backups until you do a filesystem check.

Re:fsck speed, want safety (2)

grumbel (592662) | more than 2 years ago | (#38918263)

Yep, my last experience with fsck was after a HDD has gotten a few bad sectors. fsck on the ext3 file system let me recover the data alright, except of course for the filenames, thus I ended up with a whole lot of unsorted and unnamed stuff in /lost+found, which wasn't very helpful. I'd really like to see more focus on how secure the filesystems are and less on how fast they are.

Re:fsck speed, want safety (-1, Offtopic)

gweihir (88907) | more than 2 years ago | (#38918495)

Whats with the AC invasion? Are people so afraid these days that a pseudonym as slashdot offers is not enough?

Re:fsck speed, want safety (1)

h4rr4r (612664) | more than 2 years ago | (#38918557)

Basically that.
They don't want you to know how little they know. If they used the same name over and over that pattern would be visible.

Or maybe, yeah probably, ALIENS!

Re:fsck speed, want safety (0)

gweihir (88907) | more than 2 years ago | (#38918729)

So basically a disconnect between ego and competence and they know it. Can you get any lower? Probably not.

ALIENS would be the better option, but somehow human stupidity and cowardliness seems a lot more likely....

Re:fsck speed, want safety (1)

Grishnakh (216268) | more than 2 years ago | (#38919219)

There's no way aliens are remotely as stupid as humans, at least not if they've managed to travel to earth. We're still arguing whether we should bother going back to our nearby moon, and mostly saying we'd rather just sit around and play with piles of green paper and play Angry Birds; any culture advanced enough to travel to a different star system would be far more intelligent than us.

Re:fsck speed, want safety (1)

Anonymous Coward | more than 2 years ago | (#38919339)

I'm the OP/AC. There's no reason that I'm AC other than that I'm too lazy to create an account. I'm under no illusions as to how much or little I know, and don't care if you know my name, it's little less anonymous than Anonymous Coward.

I can't claim credit for any invasions though.

See people! Here's the danger! (0)

Anonymous Coward | more than 2 years ago | (#38917475)

What's the Damage? Measuring fsck Under XFS and Ext4 On Big Storage

Because of politically correct speech, I read the headline as "What's the Damage? Measuring fuck Under XFS and Ext4 On Big Storage"

Jessie Mother fscking crisko!

Re:See people! Here's the danger! (-1)

Anonymous Coward | more than 2 years ago | (#38917631)

Oh my god! An "I read this as..." joke! So original and funny! Hurr hurr...

Re:See people! Here's the danger! (-1)

Anonymous Coward | more than 2 years ago | (#38918027)

So, you're saying I shouldn't give up my day job?

I DON'T HAVE ONE!! HA! Jokes on you!

*crying*

fsck xfs does something? (3, Interesting)

drewstah (110889) | more than 2 years ago | (#38917591)

When I had some EBS problems a couple years ago, I figured I would run xfs_check. It seemed to do absolutely nothing, even if there were disks known to be bad in the md array. xfs is nice and fast, but I haven't seen the xfs_check or xfs_repair to do either of the things I'd assume they'd do -- check and repair. I found it easier to delete the volumes and start from scratch, because any compromised xfs filesystem seems to be totally unfixable. Is fsck for xfs new?

Re:fsck xfs does something? (2)

larry bagina (561269) | more than 2 years ago | (#38917737)

I set up an xfs volume a couple years back. After copying a few files over nfs, it became corrupted. the xfs fsck did something -- it told me that it was so corrupted, it couldn't be fixed.

Re:fsck xfs does something? (3, Informative)

Sipper (462582) | more than 2 years ago | (#38919387)

I set up an xfs volume a couple years back. After copying a few files over nfs, it became corrupted. the xfs fsck did something -- it told me that it was so corrupted, it couldn't be fixed.

I think you mean xfs_repair. On XFS, fsck is a no-op.

I've never yet seen xfs_repair tell me there was an issue it couldn't fix -- that sounds unusual. However there have been lots of changes to XFS in the Linux kernel in recent years, and occasionally there has been a few nasty bugs, some of which I ran into. Linux-2.6.19 in particular had some nasty XFS filesystem corruption bugs.

Re:fsck xfs does something? (1)

Sipper (462582) | more than 2 years ago | (#38919287)

When I had some EBS problems a couple years ago, I figured I would run xfs_check. It seemed to do absolutely nothing, even if there were disks known to be bad in the md array. xfs is nice and fast, but I haven't seen the xfs_check or xfs_repair to do either of the things I'd assume they'd do -- check and repair. I found it easier to delete the volumes and start from scratch, because any compromised xfs filesystem seems to be totally unfixable. Is fsck for xfs new?

It's not you; xfs_repair will only operate on a filesystem that is not mounted at all. In other words, if you want to run xfs_repair, you need to do it after booting a LiveCD of some kind. Even when using the -d option for "dangerous" which implies that it will operate on a filesystem mounted read-only, xfs_repair will refuse and simply quit.

However once you do boot a LiveCD and run xfs_repair, it does actaully repair an XFS filesystem. For obvious reasons this is critical to be able to do, because any improper shutdown without unmounting first will corrupt an XFS filesystem.

I've been running XFS for several years on my laptop, and recently even use XFS on top of encypted LUKS. This is probably a fairly rare setup but I can't find anything better because I like the speed the XFS filesystem allows. Using XFS I'm able to transfer 40 MiB/s solid via FTP over 1Gb ethernet even with LUKS encyption, but can't get any more than about 30 MiB/s (and which speed varies) when using EXT4. However I know EXT4 is safer to use.

The only thing I (sort of) regret) was to use XFS on a remote server. If the power drops I'll have to have the ISP give me a remote KVM connection over IP and tell them to insert a Linux LiveCD to allow me to recover the XFS filesystems. That's a bit inconvenient -- however thankfully the ISP the box is hosted with (CoreNetworks.net) will actually do all of that at no cost, so I can at least deal with the problem if it ever happens.

Why bother? (1)

Waffle Iron (339739) | more than 2 years ago | (#38917593)

They're testing 70 TB of storage, so with current hard drive quality, the odds of an unrecoverable read error are probably close to 100%. It would be simpler to write a two-line fsck utility to report it:

#!/bin/sh
exit 1

Re:Why bother? (1)

pankkake (877909) | more than 2 years ago | (#38917939)

Except they were using RAID60.

Re:Why bother? (1)

_LORAX_ (4790) | more than 2 years ago | (#38918497)

Unless every read does a checksum ( they don't or it would kill performance ) then there is still the possibility of a silent read corruption. At 70TB it would be rare, but not as rare as many would think and would depend on the sector size and checksum on the individual drives.

Re:Why bother? (1)

isorox (205688) | more than 2 years ago | (#38918759)

Unless every read does a checksum ( they don't or it would kill performance ) then there is still the possibility of a silent read corruption. At 70TB it would be rare, but not as rare as many would think and would depend on the sector size and checksum on the individual drives.

Ideally you'd have something like zfs's scrubbing in the background. Or keep it in the application level (the application stores metadata about the files, may as wel throw in a checksum on create, then have a background checker), however a 1 bit error in an mpeg file isn't important.

And when you're creating and destroying data at multi-gigabit speed, how do you perform backups?

Re:Why bother? (1)

colinrichardday (768814) | more than 2 years ago | (#38919123)

Unless every read does a checksum ( they don't or it would kill performance )

How does that relate to using the journal checksum option on ext4?

Re:Why bother? (1)

_LORAX_ (4790) | more than 2 years ago | (#38919241)

jornal checksumming only prevents errors in the journal, not once the data has been written to the main storage area. This was done primarily to ensure the atomic nature of the journal is not violated by a partial write.

Re:Why bother? (2)

_LORAX_ (4790) | more than 2 years ago | (#38918093)

After evaluating our options in the 50-200TB range with room for further growth we ended up moving away from linux and to an object based storage platform with a pooled, snapshotted, and checksummed design. One of the major reasons for this was the URE problem, we would virtually be guaranteeing silent data corruption at that size with a filesystem that did not have internal checksums. The closest thing in the OS world would be ZFS whose openness is in serious doubt. It is scary how much trust the community places on spinning rust.

The tests are also useless since the "speed" will be linerally controlled by the IOPS of the array. Sure would be nice to be able to throw 10x15k spindles at 3.5TB ( 230 disks for the 72TB test ) that's one way to improve random IO performance, but how many can afford such luxury on a big data store that could reach into the 100's of TB?

Re:Why bother? (0)

Anonymous Coward | more than 2 years ago | (#38918163)

Hi can you explain what "URE problem" means ? thanks!

Re:Why bother? (1)

Nick Ives (317) | more than 2 years ago | (#38919255)

Unrecoverable read error. It was mentioned in the OP.

If you have a 200TB hard disk array then it's certain that you will encounter data corruption.

Re:Why bother? (0)

Anonymous Coward | more than 2 years ago | (#38918321)

I'd say ZFS is the bastion of hope in the current environment. Would you recommend going with some even more proprietary system? ZFS runs well on Solaris, OpenIndiana and BSD, and addresses every problem you mentioned and dozens more. If you have an issue with ZFS, Oracle Linux (also free, also open source) now 'ships' with BTRFS as the standard file system, giving you yet another great option.

Re:Why bother? (3, Interesting)

_LORAX_ (4790) | more than 2 years ago | (#38918647)

Our BTRFS evaluation resulted in rejecting it for some very serious problems ( what they claim are snapshots are actually clones, panic in low memory situations, no fsck, horrible support tools, developers who are hostile to criticism, pre-release software, ... ). ZFS was nice, but limited to non-distributed systems and still had a non-trivial amount of volume and backend management headaches. Personally I use ZFS for my personal servers at home ( incremental snapshots are the bomb ) but out production systems needed more.

Re:Why bother? (3, Interesting)

Guspaz (556486) | more than 2 years ago | (#38919467)

ZFS now runs pretty well on Linux too, as a kernel module, thanks to zfsonlinux. If you're running a Debian-based distro, installing it is trivial (one command to add the PPA, one command to install the package).

Object based storage (1)

Al Kossow (460144) | more than 2 years ago | (#38918483)

What system did you end up going with?

How do you back it up?

Re:Why bother? (0)

Anonymous Coward | more than 2 years ago | (#38918437)

xfs is a good file system however some of us wonder if making a 300TB file system at work was a great idea :)

Re:Why bother? (1)

_LORAX_ (4790) | more than 2 years ago | (#38919313)

Well since anything over 100TB is not supported by the vendor I would say not really a great idea. The reason it's not supported is there is no reasonable way to maintain ( things like an error would result in days worth of outages to fsck and/or restore from backup ).

Re:Why bother? (1)

gweihir (88907) | more than 2 years ago | (#38918525)

They're testing 70 TB of storage, so with current hard drive quality, the odds of an unrecoverable read error are probably close to 100%. It would be simpler to write a two-line fsck utility to report it:

#!/bin/sh
exit 1

That is only when you use the minimal guarantees from the datasheets. In practice, with healthy disks, read errors are a lot less common.

Re:Why bother? (1)

_LORAX_ (4790) | more than 2 years ago | (#38919267)

That is only when you use the minimal guarantees from the datasheets. In practice, with healthy disks, read errors are a lot less common.

Are you willing to bet 70TB+ on it, because that's what you are doing.

Breaking News! (2, Funny)

Anonymous Coward | more than 2 years ago | (#38917601)

This just in:

Full filesystem scans take longer as the size of the filesystem increases.

News at 11.

Re:Breaking News! (0)

Anonymous Coward | more than 2 years ago | (#38918657)

You forgot "this somehow proves that Linux sucks".

Fsck times (0)

Anonymous Coward | more than 2 years ago | (#38917689)

For the FSCK times of EXT4 on 50% loaded 72TB (32TB, 105million files) drive the time was only an hour. I wish my drives at home would FSCK that fast, and I only have 2 TB formatted XFS

Re:Fsck times (2)

Gazzonyx (982402) | more than 2 years ago | (#38919029)

They were using 15K RPM SAS drives. Your 7200 RPM drives aren't going to touch the speed of 15K RPM drives on a SAS backplane. Not by a long shot.

Damage? (3, Funny)

eggstasy (458692) | more than 2 years ago | (#38917765)

Honey badger don't give a fsck.

Who would engineer a storage system like that? (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38917967)

A single file system that big without checking features that file systems like ZFS or clustering file stores provide seems insane to me.

poor test.. bad results (1)

_LORAX_ (4790) | more than 2 years ago | (#38918181)

A much better test of linux "big data"

1) write garbage to X blocks
2) run fsck if no errors found, repeat step 1

How long would it take before either of these filesystems noticed a problem and how many corrupt files do you have? With a real filesystem you should be able to identify and/or correct the data before it takes out any real data.

Article correction (0)

Anonymous Coward | more than 2 years ago | (#38918317)

The lengthy delay in obtaining the results is due to the lack of hardware for testing time waiting for fsck to finish.

So? (0)

Anonymous Coward | more than 2 years ago | (#38918425)

Okay, so ext4 takes longer to fsck than XFS does.

Let's look at how they set up the scenario. They made a bunch of RAID6's with two spares each, and *then* made a striped RAID of those to get 72TB. This tells me that they're storing data where uptime is paramount. So, you're not in an organization where you can answer the red phone in your server room and go "Well, we're checking the drive for errors. Our 72TB of business data will be back on line in about a half-hour". So, you've certainly got hot-spares for fail-over, right?... which means that it kinda doesn't matter *how* long your primary is down (within reason, of course). I say "within reason" because the biggest discrepancy I see in their results between ext4 and XFS is about a factor of x8 (about a half-hour for ext4 as opposed to XFS's 4.5 minutes)

Their message seems to be that, if you've got 72TB of data on an array with ext4 and your only way of getting it back is with fsck, you're in a bit of trouble.

Personally, I'd shorten the message by taking the "with ext4" part out.

Re:So? (1)

Guspaz (556486) | more than 2 years ago | (#38919493)

Isn't that the point of using a filesystem that can do online scrubs, like ZFS? As far as I know, ZFS also checks metadata when scrubbing.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...