partition> p
Current partition table (original):
Total disk cylinders available: 14087 + 2 (reserved cylinders)

Part Tag Flag Cylinders Size Blocks
0 root wm 0 - 5031 48.83GB (5032/0/0) 102411264
1 swap wu 5032 - 6642 15.63GB (1611/0/0) 32787072
2 backup wm 0 - 14086 136.71GB (14087/0/0) 286698624
3 var wm 6643 - 7649 9.77GB (1007/0/0) 20494464
4 unassigned wm 7650 - 8656 9.77GB (1007/0/0) 20494464
5 unassigned wm 8657 - 10669 19.54GB (2013/0/0) 40968576
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 0 0 (0/0/0) 0


i want to create a partition on s7 with 200 mb can i create a partition with partition table on harddisk or not.

Yes, you have about 33 GB free.

can you please tell how we can create the partition with steps ...

You're already in the partition command. It prints the menu at each stage, and you are already down in the section looking at the partition table for that drive. If you really want to put the remaining space on s7, then choose 7, give it a starting position of the first unused cylinder (10670) and an end position of the last available cylinder (14086). Print (p) the resulting partition table and proof read what you did. Then write it out to the disk and quit. You have to be very careful when doing this since it is your live drive.

When done with partition, do a `newfs /dev/dsk/cxtxdxs7`. I can't tell what those x's should be from what you provided, but they were displayed when you entered the partition command.

Then you should add an entry for s7 to /etc/vfstab.

Finally, mkdir the mount point you want to use (it should be in the /etc/vfstab entry) and mount it.

Or better if you are using Solaris 10 or newer: and that's it.

Well, yeah, but I prefer to do whole drives with zfs. Also, you just have a pool, so that's not quite it. You also need to do

And, you also have to learn zfs. Which you should. But, if everything you have is ufs, and you just want to add the s7 partition, then . . .

Also, "better" is often relative to the particulars of the situation. I recently found a case where I had zfs and needed to change back to ufs. I had clients using rsync with --link-dest dumping large numbers of hard links on the server share. I wanted to roll that into the Amanda backups to put it into the tape cycle, shorten the rsync cycle, and reduce the space used on disk. However, gnu tar chokes on all those hard links (when doing incrementals), zfs send doesn't do incrementals, and there were really no options for zfs. ufsdump, on the other hand handles the situation. It allows me to roll the rsync stuff into the Amanda tape backups and get the advantage of Amanda's planner and smoothing of resource usage over the dump cycle. Other than that example, I have been pushing to zfs for almost all new resources and redoing older things in zfs as resources allow.

So do I but ZFS on partitions or slices still works quite well.
Although it is a good practice, you don't need to create a filesystem in the tank. A file system is always created by default on the top of every newly created pool.Indeed, but managing ZFS is much simpler than any other volume management & file system and has a ton of advantages compared to UFS.
Sure, I was talking about Solaris 10 and newer, if you are running Solaris 9, 8 or whatever, UFS is the best way to go.
I see, but as you explain it, it looks to be a GNU tar shortcoming, not a ZFS one. In any case, ZFS has its own way of doing backups, including incrementals with snapshots. Quoting http://www.solarisinternals.com/wiki...ractices_Guide

You can create an incremental snapshot stream (see "zfs send -i" syntax). This is generally much faster than incremental backups performed by file-level tools, such as tar and rsync, because ZFS already knows which blocks have changed on disk, and it can simply read those blocks as large sequential disk read operations, to the extent physically possible. Archive tools, such as tar and rsync, must walk the file system, checking every file and directory for modifications, in order to choose which files have changed and need to be included in the incremental backup.

So do I !

The hangup with the zfs send/receive for backups is that send/receive, as I understand it, is an all or nothing operation. You cannot extract just one file from the backup stream, as you can with ufsrestore. So, although Amanda can use zfs send/receive, it has limitations, and is not regarded as an enterprise backup/recovery tool. That's why I use gnu tar on zfs file systems. I don't have a good solution for a zfs file system loaded with hard links.

For single file recovery, I would recommend using local snapshots, assuming enough space is available to keep enough of them.