# $Id: TODO,v 2.5 2012/10/31 19:36:51 ksb Exp $

This product does what I needed it to do.  Bugs reports welcome.

AIX (IBMR2) we can't read/parse /etc/filesystems.  The stanza file
format is odd enough, but we need to track "log" and "dev" to swap.

LINIX, we don't copy the boot disk label correcly, we need something
like:
	sfdisk -d /dev/cciss/c0d0 | sfdisk /dev/cciss/c0d1

Add -H help or -H percent to explain the percent markup?

Document:
---------
 -a is a _lot_ faster than you'd think, on FreeBSD.
 -B/-A -D/-I if we can figure out how to explain them.
 -Hdd:bs=126b default.


Mostly Done (but not credited or visible):
-----------
The -L cmd to label the disk.  Default none. (Done, in BUGs in man page.)

The -B cmd to take an action before you start a fs sync (for each
partition). Default to no action. (Done, in BUGs in man page.)

The -A cmd to take some action after the sync'd partition is done.
Default to no action or "sync".  (Done, in BUGs in man page.)

The -D/-I tunes to specify the recommended percent full you want
the file-system to be with Inode/Data blocks (-j uses these).


Todo:
-----

Add more checks to the "sane" meta dump check:
	Check each primary -> backup pair size, backup should be same
		size or bigger than primary's used.  got stuck here,
		how big is a device?  (lseek doesn't work) I can't
		tell without a mount of it, and a filesystem on it.
	Check that backups/primary partitions are not in the same
		volume (ouch, that's harder)  it is too Old School
		to believe major/minor rules now days.  Sigh.
	Check the fsck pass numbers on the other slices (those not
		in the primary/alternate mapping.

Make sbp work on OS X (clue: to copy bootblocks, we want to use bless(8),
the -plist option might be useful as it outputs XML that bless should be
able to parse itself).


Fix -j so that the lower bound on byte-per-inode is the frag size for
the file system (1024 or 2048 or 4096), and set the frag size and block
size base on the bytes-per-inode and size of the disk.  This is a bit of
a feed-back loop, but I think it can be done.  (I do it myself for stuff
I build.)

But silly newfs does strange errors for reasonable requests, and doesn't
have any mode to check the params (or documented way to predict anything).

Do we have to add "-o prop" to ask -j to diddle all of newfs's
params?  There is so much it could do: but brain-dead newfs/mkfs
doesn't help.  And Sun reps hate it when you _use_ a newfs tune,
and issues with the disk and they tell you to take out -c, -t, -i,
and the like.  Double sigh.

Some options to "dump" (cum ufsdump) need to be HOSTTYPE specific.


Ideas:
------
Add a method (from ab@ics.purdue.edu) to rsync to a rsync server
with a login and password to "backup" any dataless workstation.
	sbp -H rput:user@host
or some such.  One can put in fstab (cum checklist/vfstab/filesystems)
	center.foo.com:/archive/lv426 /backup nfs ...
to dump the stuff through NFS, but to an rsync port would be much faster.

This might require reading the comments in /etc/vfstab for a clue or
two, or taking a "noauto" "NFS" entry to pull the rsync params.
	server.baz.com:/dumps/localname	/backup	nfs noauto 1 1
Might mean
	rsync [opts] /  server.baz.com:/dumps/localname
the fstab/vfstab/checklist update would be OK, but the filesystem type
would have to be swapped as well.  Humm.  Might be easier in that case
to swap the mount-point?  (Or make it a wrapper, or not do it with -F.)

Might be implemented as a script, actually with a -H umount.


Maybe implement -i.  This would ask "ynfh" (yes, no, next file system,
help) for each command presented.  Not very useful in this program.
Oh, and -i should (maybe) leverage Sun5 newfs's penchant for asking
stupid questions. (As well as unsing rm -i.)  This would require a
slight extension to the internal command table (like vi's terse messages).


--
ksb, Dec 2005