> I had about 250GB of real files (over 400GB in the virtual pool). I never had > any disk corruption.
In my case it didn't show up until i had about 4T in the virtual pool, with about 350GB of real files. I also noticed somewhere along the line that i had LOTS of identical small files from someone's logging project gone awry; thousands of them on one server. That had to up my link count. > => I'd blame my hardware if i hadn't had similar experiences several years > => ago (on solaris) with an application that was written to use flat files > => as a "database". > > I've administered Solaris for over 12 years, and have never seen the kind of I've administered solaris for about 16 years. > filesystem corruption that you describe--aside from hardware probelms. I'd > seriously examine your hardware (not just the disk subsystem, but memory as > well). I've seen it twice now myself. In the first instance I am 100% sure it was not the hardware. This time it's possible, i haven't exhaustively tested it; but it's not crap hardware. > => the filesystem just didn't like lots and lots of small files and the > > Huh? UFS is fine with "lots and lots" of small files--and performs much better > than ext[23]fs under similar circumstances. The filesystem workload you're > describing is typical of some mail servers, and many NNTP servers--both common > applications for Solaris. You're certainly right; lots of people use solaris on these kind of loads. All I know is that twice now in the described circumstances I've had problems. Actually, I can think of a third instance, when a problem like this was reported on the openafs list by someone using the namei fileserver on solaris. and under extreme load it apparently dies. I can't tell you why, I can just tell you what we observed. I should add that in the previous instance where i ran into it, I was the junior admin and the senior guy had about 20 years' experience. Unfortunately we couldn't replicate it reliably, and I can't do so this time. > => system panicked every few weeks, and fsck took FOREVER. I'm guessing > > Well, yes, fsck will take a very long time. Do you have journalling turned on > as a filesystem mount option? Of course I have journalling turned on (if i recall correctly, it's the default on solaris 10). the filesystem needs an fsck to repair the corruption. Typically it's been "unexpected unallocated inode" errors. > What is the average size of your files? Have you tuned the file system (block > size, number of inodes, etc.) for that type of file? I'm using the default block size; I have plenty of inodes. > Um, as far as I know, ZFS has been in general release for over a year > already, (and in > limited release since late 2004). Yup. And in my book, that's not mature. Go read the zfs list on opensolaris.org. Some folks are extremely happy; others have trouble. Bugs are getting filed (and fixed, I'm sure; I'm just afraid of the bleeding edge. > I want a newsgroup with a infinite S/N ratio! Now taking CFV on: > rec.motorcycles.stagehands.pet-bird-owners.pinballers.unix-supporters > 15+ So Far--Want to join? Check out: http://www.panix.com/~bergman Sorry, I don't own a bird. And I haven't been a stagehand for 20 years although i'm sure that won't stop me from pithy ruminations. danno -- Dan Pritts, System Administrator Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ BackupPC-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
