The dot in ... --- ...
Chris Gerhard's Weblog
Saturday March 28, 2009
snapshot on unlink? This thread on OpenSolaris made me wonder how hard it would be to take a snapshot before any file is deleted. It turns out that using dtrace it is not hard at all. Using dtrace to monitor unlink and unlinkat calls and a short script to take the snapshots:
#!/bin/ksh93
function snapshot
{
eval $(print x=$2)
until [[ "$x" == "/" || -d "$x/.zfs/snapshot" ]]
do
x="${x%/*}"
done
if [[ "$x" == "/" || "$x" == "/tmp" ]]
then
return
fi
if [[ -d "$x/.zfs/snapshot" ]]
then
print mkdir "$x/.zfs/snapshot/unlink_$1"
pfexec mkdir "$x/.zfs/snapshot/unlink_$1"
fi
}
function parse
{
eval $(print x=$4)
if [[ "${x%%/*}" == "" ]]
then
snapshot $1 "$2$4"
else
snapshot $1 "$2$3/$4"
fi
}
pfexec dtrace -wqn 'syscall::fsat:entry /pid != '$$' && uid > 100 && arg0 == 5/ {
printf("%d %d \"%s\" \"%s\" \"%s\"\n",
pid, walltimestamp, root, cwd, copyinstr(arg2)); stop()
}
syscall::unlink:entry /pid != '$$' && uid > 100 / {
printf("%d %d \"%s\" \"%s\" \"%s\"\n",
pid, walltimestamp, root, cwd, copyinstr(arg0)); stop()
}' | while read pid timestamp root cwd file
do
print prun $pid
parse $timestamp $root $cwd $file
pfexec prun $pid
done
Now this is just a Saturday night proof of concept and it should be noted it has a significant performance impact and single threads all calls to unlink.
Also you end up with lots of snapshots:
cjg@brompton:~$ zfs list -t snapshot -o name,used | grep unlink rpool/export/home/cjg@unlink_1238270760978466613 11.9M rpool/export/home/cjg@unlink_1238275070771981963 59K rpool/export/home/cjg@unlink_1238275074501904526 59K rpool/export/home/cjg@unlink_1238275145860458143 34K rpool/export/home/cjg@unlink_1238275168440000379 197K rpool/export/home/cjg@unlink_1238275233978665556 197K rpool/export/home/cjg@unlink_1238275295387410635 197K rpool/export/home/cjg@unlink_1238275362536035217 197K rpool/export/home/cjg@unlink_1238275429554657197 136K rpool/export/home/cjg@unlink_1238275446884300017 350K rpool/export/home/cjg@unlink_1238275491543380576 197K rpool/export/home/cjg@unlink_1238275553842097361 197K rpool/export/home/cjg@unlink_1238275643490236001 63K rpool/export/home/cjg@unlink_1238275644670212158 63K rpool/export/home/cjg@unlink_1238275646030183268 0 rpool/export/home/cjg@unlink_1238275647010165407 0 rpool/export/home/cjg@unlink_1238275648040143427 54K rpool/export/home/cjg@unlink_1238275649030124929 54K rpool/export/home/cjg@unlink_1238275675679613928 197K rpool/export/home/cjg@unlink_1238275738608457151 198K rpool/export/home/cjg@unlink_1238275800827304353 57.5K rpool/export/home/cjg@unlink_1238275853116324001 32.5K rpool/export/home/cjg@unlink_1238275854186304490 53.5K rpool/export/home/cjg@unlink_1238275862146153573 196K rpool/export/home/cjg@unlink_1238275923255007891 55.5K rpool/export/home/cjg@unlink_1238275962114286151 35.5K rpool/export/home/cjg@unlink_1238275962994267852 56.5K rpool/export/home/cjg@unlink_1238275984723865944 55.5K rpool/export/home/cjg@unlink_1238275986483834569 29K rpool/export/home/cjg@unlink_1238276004103500867 49K rpool/export/home/cjg@unlink_1238276005213479906 49K rpool/export/home/cjg@unlink_1238276024853115037 50.5K rpool/export/home/cjg@unlink_1238276026423085669 52.5K rpool/export/home/cjg@unlink_1238276041792798946 50.5K rpool/export/home/cjg@unlink_1238276046332707732 55.5K rpool/export/home/cjg@unlink_1238276098621721894 66K rpool/export/home/cjg@unlink_1238276108811528303 69.5K rpool/export/home/cjg@unlink_1238276132861080236 56K rpool/export/home/cjg@unlink_1238276166070438484 49K rpool/export/home/cjg@unlink_1238276167190417567 49K rpool/export/home/cjg@unlink_1238276170930350786 57K rpool/export/home/cjg@unlink_1238276206569700134 30.5K rpool/export/home/cjg@unlink_1238276208519665843 58.5K rpool/export/home/cjg@unlink_1238276476484690821 54K rpool/export/home/cjg@unlink_1238276477974663478 54K rpool/export/home/cjg@unlink_1238276511584038137 60.5K rpool/export/home/cjg@unlink_1238276519053902818 71K rpool/export/home/cjg@unlink_1238276528213727766 62K rpool/export/home/cjg@unlink_1238276529883699491 47K rpool/export/home/cjg@unlink_1238276531683666535 3.33M rpool/export/home/cjg@unlink_1238276558063169299 35.5K rpool/export/home/cjg@unlink_1238276559223149116 62.5K rpool/export/home/cjg@unlink_1238276573552877191 35.5K rpool/export/home/cjg@unlink_1238276584602668975 35.5K rpool/export/home/cjg@unlink_1238276586002642752 53K rpool/export/home/cjg@unlink_1238276586522633206 51K rpool/export/home/cjg@unlink_1238276808718681998 216K rpool/export/home/cjg@unlink_1238276820958471430 77.5K rpool/export/home/cjg@unlink_1238276826718371992 51K rpool/export/home/cjg@unlink_1238276827908352138 51K rpool/export/home/cjg@unlink_1238276883227391747 198K rpool/export/home/cjg@unlink_1238276945366305295 58.5K rpool/export/home/cjg@unlink_1238276954766149887 32.5K rpool/export/home/cjg@unlink_1238276955946126421 54.5K rpool/export/home/cjg@unlink_1238276968985903108 52.5K rpool/export/home/cjg@unlink_1238276988865560952 31K rpool/export/home/cjg@unlink_1238277006915250722 57.5K rpool/export/home/cjg@unlink_1238277029624856958 51K rpool/export/home/cjg@unlink_1238277030754835625 51K rpool/export/home/cjg@unlink_1238277042004634457 51.5K rpool/export/home/cjg@unlink_1238277043934600972 52K rpool/export/home/cjg@unlink_1238277045124580763 51K rpool/export/home/cjg@unlink_1238277056554381122 51K rpool/export/home/cjg@unlink_1238277058274350998 51K rpool/export/home/cjg@unlink_1238277068944163541 59K rpool/export/home/cjg@unlink_1238277121423241127 32.5K rpool/export/home/cjg@unlink_1238277123353210283 53.5K rpool/export/home/cjg@unlink_1238277136532970668 52.5K rpool/export/home/cjg@unlink_1238277152942678490 0 rpool/export/home/cjg@unlink_1238277173482320586 0 rpool/export/home/cjg@unlink_1238277187222067194 49K rpool/export/home/cjg@unlink_1238277188902043005 49K rpool/export/home/cjg@unlink_1238277190362010483 56K rpool/export/home/cjg@unlink_1238277228691306147 30.5K rpool/export/home/cjg@unlink_1238277230021281988 51.5K rpool/export/home/cjg@unlink_1238277251960874811 57K rpool/export/home/cjg@unlink_1238277300159980679 30.5K rpool/export/home/cjg@unlink_1238277301769961639 50K rpool/export/home/cjg@unlink_1238277302279948212 49K rpool/export/home/cjg@unlink_1238277310639840621 28K rpool/export/home/cjg@unlink_1238277314109790784 55.5K rpool/export/home/cjg@unlink_1238277324429653135 49K rpool/export/home/cjg@unlink_1238277325639636996 49K rpool/export/home/cjg@unlink_1238277360029166691 356K rpool/export/home/cjg@unlink_1238277375738948709 55.5K rpool/export/home/cjg@unlink_1238277376798933629 29K rpool/export/home/cjg@unlink_1238277378458911557 50K rpool/export/home/cjg@unlink_1238277380098888676 49K rpool/export/home/cjg@unlink_1238277397738633771 48K rpool/export/home/cjg@unlink_1238277415098386055 49K rpool/export/home/cjg@unlink_1238277416258362893 49K rpool/export/home/cjg@unlink_1238277438388037804 57K rpool/export/home/cjg@unlink_1238277443337969269 30.5K rpool/export/home/cjg@unlink_1238277445587936426 51.5K rpool/export/home/cjg@unlink_1238277454527801430 50.5K rpool/export/home/cjg@unlink_1238277500967098623 196K rpool/export/home/cjg@unlink_1238277562866135282 55.5K rpool/export/home/cjg@unlink_1238277607205456578 49K rpool/export/home/cjg@unlink_1238277608135443640 49K rpool/export/home/cjg@unlink_1238277624875209357 57K rpool/export/home/cjg@unlink_1238277682774484369 30.5K rpool/export/home/cjg@unlink_1238277684324464523 50K rpool/export/home/cjg@unlink_1238277685634444004 49K rpool/export/home/cjg@unlink_1238277686834429223 75.5K rpool/export/home/cjg@unlink_1238277700074256500 48K rpool/export/home/cjg@unlink_1238277701924235244 48K rpool/export/home/cjg@unlink_1238277736473759068 49.5K rpool/export/home/cjg@unlink_1238277748313594650 55.5K rpool/export/home/cjg@unlink_1238277748413593612 28K rpool/export/home/cjg@unlink_1238277750343571890 48K rpool/export/home/cjg@unlink_1238277767513347930 49.5K rpool/export/home/cjg@unlink_1238277769183322087 50K rpool/export/home/cjg@unlink_1238277770343306935 48K rpool/export/home/cjg@unlink_1238277786193093885 48K rpool/export/home/cjg@unlink_1238277787293079433 48K rpool/export/home/cjg@unlink_1238277805362825259 49.5K rpool/export/home/cjg@unlink_1238277810602750426 195K rpool/export/home/cjg@unlink_1238277872911814531 195K rpool/export/home/cjg@unlink_1238277934680920214 195K rpool/export/home/cjg@unlink_1238277997220016825 195K rpool/export/home/cjg@unlink_1238278063868871589 54.5K rpool/export/home/cjg@unlink_1238278094728323253 61K rpool/export/home/cjg@unlink_1238278096268295499 63K rpool/export/home/cjg@unlink_1238278098518260168 52K rpool/export/home/cjg@unlink_1238278099658242516 56K rpool/export/home/cjg@unlink_1238278103948159937 57K rpool/export/home/cjg@unlink_1238278107688091854 54K rpool/export/home/cjg@unlink_1238278113907980286 62K rpool/export/home/cjg@unlink_1238278116267937390 64K rpool/export/home/cjg@unlink_1238278125757769238 196K rpool/export/home/cjg@unlink_1238278155387248061 136K rpool/export/home/cjg@unlink_1238278160547156524 229K rpool/export/home/cjg@unlink_1238278165047079863 351K rpool/export/home/cjg@unlink_1238278166797050407 197K rpool/export/home/cjg@unlink_1238278168907009714 55K rpool/export/home/cjg@unlink_1238278170666980686 341K rpool/export/home/cjg@unlink_1238278171616960684 54.5K rpool/export/home/cjg@unlink_1238278190336630319 777K rpool/export/home/cjg@unlink_1238278253245490904 329K rpool/export/home/cjg@unlink_1238278262235340449 362K rpool/export/home/cjg@unlink_1238278262915331213 362K rpool/export/home/cjg@unlink_1238278264915299508 285K rpool/export/home/cjg@unlink_1238278310694590970 87K rpool/export/home/cjg@unlink_1238278313294552482 66K rpool/export/home/cjg@unlink_1238278315014520386 31K rpool/export/home/cjg@unlink_1238278371773568934 258K rpool/export/home/cjg@unlink_1238278375673503109 198K rpool/export/home/cjg@unlink_1238278440802320314 138K rpool/export/home/cjg@unlink_1238278442492291542 55.5K rpool/export/home/cjg@unlink_1238278445312240229 2.38M rpool/export/home/cjg@unlink_1238278453582077088 198K rpool/export/home/cjg@unlink_1238278502461070222 256K rpool/export/home/cjg@unlink_1238278564359805760 256K rpool/export/home/cjg@unlink_1238278625738732194 63.5K rpool/export/home/cjg@unlink_1238278633428599541 61.5K rpool/export/home/cjg@unlink_1238278634568579678 137K rpool/export/home/cjg@unlink_1238278657838186760 288K rpool/export/home/cjg@unlink_1238278659768151784 223K rpool/export/home/cjg@unlink_1238278661518121640 159K rpool/export/home/cjg@unlink_1238278664378073421 136K rpool/export/home/cjg@unlink_1238278665908048641 138K rpool/export/home/cjg@unlink_1238278666968033048 136K rpool/export/home/cjg@unlink_1238278668887996115 281K rpool/export/home/cjg@unlink_1238278670307970765 227K rpool/export/home/cjg@unlink_1238278671897943665 162K rpool/export/home/cjg@unlink_1238278673197921775 164K rpool/export/home/cjg@unlink_1238278674027906895 164K rpool/export/home/cjg@unlink_1238278674657900961 165K rpool/export/home/cjg@unlink_1238278675657885128 165K rpool/export/home/cjg@unlink_1238278676647871187 241K rpool/export/home/cjg@unlink_1238278678347837775 136K rpool/export/home/cjg@unlink_1238278679597811093 199K rpool/export/home/cjg@unlink_1238278687297679327 197K rpool/export/home/cjg@unlink_1238278749616679679 197K rpool/export/home/cjg@unlink_1238278811875554411 56.5K cjg@brompton:~$
Good job that snapshots are cheap. I'm not going to be doing this all the time but it makes you think what could be done.
( Mar 28 2009, 10:52:35 PM GMT ) Permalink Trackback
Saturday February 21, 2009
[Open]Solaris logfiles and ZFS root This week I had reason to want to see how often the script that controls the access hours of Sun Ray users actually did work so I went off to look in the messages files only to discover that there were only four and they only went back to January 11.
: pearson FSS 22 $; ls -l mess* -rw-r--r-- 1 root root 12396 Feb 8 23:58 messages -rw-r--r-- 1 root root 134777 Feb 8 02:59 messages.0 -rw-r--r-- 1 root root 53690 Feb 1 02:06 messages.1 -rw-r--r-- 1 root root 163116 Jan 25 02:01 messages.2 -rw-r--r-- 1 root root 83470 Jan 18 00:21 messages.3 : pearson FSS 23 $; head -1 messages.3 Jan 11 05:29:14 pearson pcplusmp: [ID 444295 kern.info] pcplusmp: ide (ata) instance #1 vector 0xf ioapic 0x2 intin 0xf is bound to cpu 1 : pearson FSS 24 $;
I am certain that the choice of only four log files was not a concious decision I have made but it did make me ponder whether logfile management should be revisted in the light of ZFS root. Since clearly if you have snapshots firing logs could go back a lot futher:
: pearson FSS 40 $; head -1 $(ls -t /.zfs/snapshot/*/var/adm/message*| tail -1) Dec 14 03:15:14 pearson time-slider-cleanup: [ID 702911 daemon.notice] No more daily snapshots left : pearson FSS 41 $;
It did not take long for this shell function to burst into life:
function search_log
{
typeset path
if [[ ${2#/} == $2 ]]
then
path=${PWD}/$2
else
path=$2
fi
cat $path /.zfs/snapshot/*$path | egrep $1 | sort -M | uniq
}
Not a generalized solution but one that works when you root filesystem contains all your logs and if you remember to escape any globbing on the command line will search all the log files:
: pearson FSS 46 $; search_log block /var/adm/messages\* | wc
51 688 4759
: pearson FSS 47 $; There are two ways to view this. Either it it great that the logs are kept and so I have all this historical data or it is a pain as getting red of log files becomes more of a chore, indeed this is encouraging me to move all the logfiles into their own file systems so that the management of those logfiles is more granular.
At the very least it seems to me that OpenSolaris should sort out where it's log files are going and end the messages going in /var/adm and move them to /var/log which then should be it's own file system.
( Feb 21 2009, 01:49:59 PM GMT ) Permalink
Tuesday November 25, 2008
Redirecting output to syslog People are always asking this and often when they are not they should be. How do you redirect all the output from a script to syslog?
The obvious is:
my_script | logger -p local6.debug -t my_script 2>&1
but how can you do that from within the script? Simple put this at the top of your script:
#!/bin/ksh
logger -p daemon.notice -t ${0##*/}[$$] |&
exec >&p 2>&1
Clearly this is korn shell specific but then who still writes bourne shell scripts. If you script was called redirect you get messages logged thus:
Nov 25 17:40:41 enoexec redirect[17449]: [ID 702911 daemon.notice] bar
( Nov 25 2008, 05:44:27 PM GMT ) Permalink Trackback
Tuesday March 11, 2008
zone copy, aka zcp. After messing around with zones for a few minutes it became clear that it would be really useful if there was a zcp command that worked just like scp(1) but used zlogin as the transport rather than using ssh. For those cases when you are root and don't want to mess with ssh authorizations since you know you can zlogin without a password anyway.
Specifically I wanted to be able to do:
# zcp /etc/resolv.conf bookable-129-156-208-37.uk:/etc
Well it turns out that this is really easy to do. The trick is to let scp(1) do the heavy lifting for you and use zlogin(1) act as your transport. So I knocked together this script. You need to install it on your path called “zcp” and then make a hard link in the same directory called “zsh”. For example:
# /usr/sfw/bin/wget --quiet http://blogs.sun.com/chrisg/resource/zcp.sh # cp zcp.sh /usr/local/bin/zcp # ln /usr/local/bin/zcp /usr/local/bin/zsh # chmod 755 /usr/local/bin/zsh
Now the glorious simplicity of zcp, I'll even trhow in recursvice copy for free:
# zcp -r /etc/inet bookable-129-156-208-37.uk:/tmp ipqosconf.1.sample 100% |*****************************| 2503 00:00 config.sample 100% |*****************************| 3204 00:00 wanboot.conf.sample 100% |*****************************| 3312 00:00 hosts 100% |*****************************| 286 00:00 ipnodes 100% |*****************************| 286 00:00 netmasks 100% |*****************************| 384 00:00 networks 100% |*****************************| 372 00:00 inetd.conf 100% |*****************************| 1519 00:00 sock2path 100% |*****************************| 566 00:00 protocols 100% |*****************************| 1901 00:00 services 100% |*****************************| 4201 00:00 mipagent.conf-sample 100% |*****************************| 6274 00:00 mipagent.conf.fa-sam 100% |*****************************| 6232 00:00 mipagent.conf.ha-sam 100% |*****************************| 5378 00:00 ntp.client 100% |*****************************| 291 00:02 ntp.server 100% |*****************************| 2809 00:00 slp.conf.example 100% |*****************************| 5750 00:00 ntp.conf 100% |*****************************| 155 00:00 ntp.keys 100% |*****************************| 253 00:00 inetd.conf.orig 100% |*****************************| 6961 00:00 ntp.drift 100% |*****************************| 6 00:00 ipsecalgs 100% |*****************************| 920 00:00 ike.preshared 100% |*****************************| 308 00:00 ipseckeys.sample 100% |*****************************| 510 00:00 datemsk.ndpd 100% |*****************************| 22 00:00 ipsecinit.sample 100% |*****************************| 2380 00:00 ipaddrsel.conf 100% |*****************************| 545 00:00 inetd.conf.preupgrad 100% |*****************************| 6563 00:00 hosts.premerge 100% |*****************************| 112 00:00 ipnodes.premerge 100% |*****************************| 61 00:00 hosts.postmerge 100% |*****************************| 286 00:00 ipqosconf.2.sample 100% |*****************************| 3115 00:00 ipqosconf.3.sample 100% |*****************************| 1097 00:00 #
I'll file and RFE for this to go into Solaris and update this entry when I have the number.
Update: The Bug ID is 6673792. The script now also supports zsync and zdist although niether of those have been tested yet.
( Mar 11 2008, 12:41:09 PM GMT ) Permalink Trackback
Thursday June 07, 2007
zfs_versions of a file This post reminds me that I should have posted my zfs_versions script a while back. I did not as it had a theoretical bug where if you could move a new file into place which had the same age as the old file it would not see this as a new version. I've fixed that now at the expense of some performance and the script is called zfs_versions.
The script lists all the different versions of a file that live in the snapshots.
Here is the output:
: pearson FSS 124 $; /home/cjg/bin/sh/zfs_versions ~/.profile /tank/fs/users/cjg/.zfs/snapshot/month_09/.profile /tank/fs/users/cjg/.zfs/snapshot/smb2007-03-27-15:54/.profile /tank/fs/users/cjg/.zfs/snapshot/minute_2007-06-06-17:30/.profile : pearson FSS 125 $;
Compare this to the number of snapshots:
: pearson FSS 128 $; ls -1 ~/.zfs/snapshot/*/.profile | wc -l
705
: pearson FSS 129 $;
So I have 705 snapshots that contain my .profile file but actually only three of them contain different versions.
Update
The addition of the check to fix the theoretical bug slows down the script enough that the programmer in me could not let it lie. Hence I now have the same thing in TCL.
Update 2
See http://blogs.sun.com/chrisg/entry/new_wish_and_tickle
( Jun 07 2007, 08:19:43 AM BST ) Permalink Trackback
Tuesday March 20, 2007
mdb pipes. Sometimes I find my self doing things that I have been doing for years and just wonder whether by now there is some tool that I have missed that makes the old way of doing something redundant. So in the off chance that I have missed something I'll document the way I often drive mdb (or more often mdb+ a slightly improved mdb that I keep wishing would get open sourced) in the hope some bright spark will point me at a better way. Failing that someone might find this useful.
When looking at crash dumps I often want to process some data and then pipe it back into mdb via some text processing tool. Now given that the startup time for mdb, particularly when running under kenv is very significant you don't want to be doing the obvious of having mdb in a typical pipeline. So while I can do this:
nawk 'BEGIN { printf("::load chain\n") }
/buf addr/ {
printf("%s::print -at buf_t av_back | ::if scsi_pkt pkt_comp == ssdintr and pkt_address.a_hba_tran->tran_tgt_init == ssfcp_scsi_tgt_init |::print -at scsi_pkt pkt_ha_private | ::print -at ssfcp_pkt cmd_flags cmd_timeout cmd_next\n",
$3) }' act.0 | kenv -x explorer_dir mdb+ 0It is a pain as kenv processes the explorer to build the correct environment and for large dumps loads the dump into memory only to throw it away.
So instead I start mdb as a cooperating process in the korn shell:
kenv -x explorer_dir mdb+ |&
Then I have a shell function called “mdbc” that will submit commands into the cooperating process and read the results back. So the above becomes:
nawk 'BEGIN { printf("::load chain\n") }
/buf addr/ {
printf("%s::print -at buf_t av_back | ::if scsi_pkt pkt_comp == ssdintr and pkt_address.a_hba_tran->tran_tgt_init == ssfcp_scsi_tgt_init |::print -at scsi_pkt pkt_ha_private | ::print -at ssfcp_pkt cmd_flags cmd_timeout cmd_next\n",
$3) }' act.0 | mdbc
or I can do
mdbc lbolt::print
Just by way of an example to show why I bother, compare the times of these two equivalent commands:
: dredd TS 243 $; time echo lbolt::print | kenv -x explorer mdb+ 0 real 0m37.03s user 0m7.02s sys 0m7.26s : dredd TS 244 $; time mdbc lbolt::print > /dev/null real 0m0.01s user 0m0.00s sys 0m0.01s : dredd TS 245 $;
and just to show that I get the right results from the mdbc command.
: dredd TS 245 $; time mdbc lbolt::print 0x496619a9 real 0m0.01s user 0m0.00s sys 0m0.01s : dredd TS 246 $;
However like talk it does have a 1980s feel to it so I look forward to hearing the error of my ways.
If you think you might find it useful the shell function is here.
Tags: debuggers mdb act Solaris ksh
( Mar 20 2007, 06:29:52 PM GMT ) Permalink
Tuesday October 24, 2006
How to delete a lot of files from a directory. If you have more than can be passed directly to a command.
v4u-3500f-gmp03 135 # rm test/test_dir/*/* /usr/bin/ksh: /usr/bin/rm: arg list too long v4u-3500f-gmp03 136 # echo test/test_dir/*/* | xargs rm v4u-3500f-gmp03 137 #
There are lots of other ways to skin this cat.
( Oct 24 2006, 02:19:57 PM BST ) Permalink Trackback
Monday June 05, 2006
Mapping disk blocks to UFS file blocks. Ever since Solaris 2.0 people have been asking for a way to map from a block on a disk back to the file which contains that block. In SunOS 4 and earlier used to have icheck(8) but that was never available in Solaris 2.0.
The answer that is usually given is short: “Use fsdb”. However fsdb is slightly less than friendly and in fact doing an exhaustive search of a file system for a particular block would be close to impossible to do by hand.
I was left thinking this must be able to be scripted. Since my particular issue was on Solaris 8 I had the added constraint that it would have to be a shell script from the choice of shells on Solaris 8.
As an example of things you can do I have written a script that will drive fsdb and can be used to:
Copy files out of unmounted file systems (with the caveat that they get padded to be whole number of blocks). I used this to test the script then compare the source file and target. I have left it in more amusement.
Find which inode and offset contains a particular disk block (blocks get specified in hex):
# icheck -d /dev/rdsk/c0d0s6 007e1590 007dd2a0 008bb6c0 inode 5c94: file block: 16#80b device block: 16#007e1590 inode 5c94: file block: 16#1ffff device block: 16#007dd2a0 inode 5c94: file block: 16#7ffffff device block: 16#008bb6c0 #
This search can be directly limited to a single inode using the -i option and an inode number (in hex).
Print the extents of a file. Again this is just mildly amusing but shows how well or badly UFS is doing laying out your files.
# icheck -d /dev/rdsk/c0t0d0s0 -x -i 186e file off 0 dev off 6684 len 1279 file off 1279 dev off 6683 len 1 #
The user interface could live with being tidied up but my original goal has been satisfied.
The script itself is not for those with a weak stomach as it works around some bugs and features in fsdb. The script is here if you wish to see the full horror.
( Jun 05 2006, 03:44:14 PM BST ) Permalink
Except where otherwise noted, this site is
licensed under a Creative Commons License 2.0
This is a personal weblog, I do not speak for my employer.
