Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
User Journal

Journal Journal: Why don't you fucks post any comments? 3

Come on, guys, I know this is the most read journal on Slashdot. So why don't you ever post any damn comments? What gives?

I'm really getting desperate. Maybe I'll shitstorm my own journal discussions, just so they look popular. Do you think that is a good idea? If so, please say so! Any input will be appreciated!

Programming

Journal Journal: Please help 1

I know C programming, but I am not a very good programmer. None of the programs I have written use more than one .c file. The thought of working on large programming projects terrifies me.

Does anyone have any advice or books I should read that will help me become a better programmer? I would greatly appreciate it. Thank you.

Comment AFS (Score 4, Informative) 36

AFS will do something like that, although not to the extent that I hear NetApp Filers can. Off the top of my head, there are two ways to do this with AFS. Both these methods require superuser access to your AFS cell, unless backups or replication releases are being done automatically.

(CodaFS should be able to do this too. I haven't played with CodaFS enough to know if it offers any other way to accomplish checkpointing.)

Method 1: backup volumes

$ cd /afs/mycell/some/path
$ kinit me/admin
Password for me/admin@MYCELL:
$ aklog
$ vos backup some.path.avol
$ kinit me
Password for me@MYCELL:
$ aklog
$ cd avol

do stuff with the filesystem...
Oops! I need files that I modified or deleted!

$ cd ..
$ fs mkm avol.backup some.path.avol.backup
$ cp avol.backup/little-lost-file avol/
$ fs rmm avol.backup

Many sites run 'vos backupsys' (generally before 'vos dump'ing volumes) every night to automatically back up all their volumes, and leave users' backup home volumes mounted under their home volumes, to provide easy access to yesterday's files without an administrator's help.

Method 2: for replicated volumes

$ cd /afs/.mycell/some/volume

do stuff - uh-oh, I need a file back that I changed!

$ cp /afs/mycell/some/volume/my/file my/file

ok, finished with the changes. Commit them!

$ kinit me/admin
Password for me/admin@MYCELL:
$ aklog
$ vos release some.volume
Released volume some.volume successfully
$ kinit me
Password for me@MYCELL:
$ aklog

Volume (for volume, read filesystem) backups work by saving the state of a volume at the time the backup command was issued. When changes are made to the volume, the original state is copied to the backup volume. The backup volume only takes as much space as the changes made since the last backup. Replication works by making read-only copies of a volume in one or more locations, as specified by 'vos addsite' commands. The copies are only updated when changes are 'released' from the read-write copy to the read-only copies. By convention, cell root volumes are mounted read-only on /afs/cellname and read-write on /afs/.cellname.

I think that newer versions of Solaris will do checkpointing on UFS. I haven't adminned Solaris since 2.3 (the slooow SS20 with 2.8 under my bed dosen't count until I play with it some more), so I'm not familiar with the details.

Slashdot Top Deals

"May the forces of evil become confused on the way to your house." -- George Carlin

Working...