I'd like to find a tool that will tell me the last sector that contains meaningful content for a given partition.

The scenario is that I have an NTFS partition that has been defragged a few times to get the unused space shifted toward the end of the partition. I want to create a minimal image that excludes the trailing unused space. I would first like to find a filesystem agnostic tool that can tell me this for any partition type. If that doesn't exist, then I would be interested in getting a tool for each of these types: NTFS, FAT16/32, ext2/3.

You could look into qtparted
http://qtparted.sourceforge.net/
(which invokes ntfresize) or ntfresize itself
http://man.linux-ntfs.org/ntfsresize.8.html
for just the NTFS partion... but be prepared
to do some careful reading and planning if you
use ntfsresize as a stand alone...

I'm not sure it's possible. I think in most filesystems timestamps are kept on a per-file basis, not at the disk block/cluster level. What you could do is write a program to scan a filesystem for the last used files, and then get the blocks used from that maybe, although I don't know what mechanism you'd use to get the blocklist.

*edit* just as I hit post I realised you're not talking about last as in time, but last as in physical position on the disk... Ignore what I said.

It seems that--unless you have total knowledge of how a filesystem works--it would be very iffy trying to image only part of a partition. I have successfully re-sized NTFS partitions with QTParted--why not go that way?

OR:
Can you not make a full partition image and then compress it?

ntfsclone can do this, see the above link for linux-ntfs.org.

If you have a partition with the unused blocks filled with 0's then you will be able to compress the image file well.

Oops, I notice that you're not a new user...
Perhaps the system tool debugfs
I.E.,
usr@host:~$ man 8 debugfs
might be of use for examining the ext2/ext3 filesystems.
IIRC GNU parted:
http://www.gnu.org/software/parted/index.shtml
should be able to resize these and the fat partions

Thanks for the help folks.

So you're essentially saying shrink it to be as small as possible, image it, then expand it back prior to using it? It appears that the union of GNU Parted and QTParted will shrink anything (excluding Fat12 and HFS). So that may indeed be the answer, but I'd prefer not to tamper with the original partition more than I must.

I was curious how the Smart Boot Manager floppy might have been created. It's a floppy image that is much smaller than 1440k - which is unusual. Compression was not used. Someone has figured out how to use dd in a way that excludes the unused space. Someone could write that SBM floppy to a 720k disk if they wanted. Noticing this is what set me on this mission.

I don't have a specific need for what I'm asking at the moment, but I would like to know how to avoid compression for a couple reasons. Uncompressed images are directly mountable. The other disadvantage to simply compressing the thing is that it must be restored onto a partition of equal or larger size to the original parition. What if the target partition is smaller than the image, but larger than the content?

Even better, if I zeroize the unused space then I might not even have to use compression, because when 'conv=notrunc' is not passed to dd, "multiple blocks of zeros get abbreviated with a string of asterisks, saving a lot of space," according to the dd tutorial. But the issue would still remain that the target partition must not be smaller than the original.

It just occured to me that perhaps I could fill the unused portions with zeros, then pipe a dd partition reading through a tool that reverses everything (so the output stream begins with the end of the device, and moves forward). Then it would just be a matter of counting zeros until the first non-zero is reached, and subtracting that number from the actual ending. Does that sound practical?

It could be problematic if the last piece of content contains meaningful zeros, but the workaround for that may be just to allow for a sufficient buffer of zeros at the end.

I just took a look at it. I will probably use that for NTFS partitions from now on.

The problem remains unsolved for non-ntfs filesystems.