On 13/06/11 11:36 AM, Jim Klimov wrote:
Some time ago I wrote a script to find any "duplicate" files and replace
them with hardlinks to one inode. Apparently this is only good for same
files which don't change separately in future, such as distro archives.
I can send it to you offlist, but it would be slow in your case
because it
is not quite the tool for the job (it will start by calculating checksums
of all of your files ;) )
What you might want to do and script up yourself is a recursive listing
"find /var/opt/SUNWmsqsr/store/partition... -ls". This would print you
the inode numbers and file sizes and link counts. Pipe it through
something like this:
find ... -ls | awk '{print $1" "$4" "$7}' | sort | uniq
And you'd get 3 columns - inode, count, size
My AWK math is a bit rusty today, so I present a monster-script like
this to multiply and sum up the values:
( find ... -ls | awk '{print $1" "$4" "$7}' | sort | uniq | awk '{
print $2"*"$3"+\\" }'; echo 0 ) | bc
This looks something like what I thought would have to be done, I was
just looking
to see if there was something tried and tested before I had to invent
something. I was really hoping
in zdb there might have been some magic information I could have tapped
into.. ;)
Can be done cleaner, i.e. in a PERL one-liner, and if you have
many values - that would probably complete faster too. But as
a prototype this would do.
HTH,
//Jim
PS: Why are you replacing the cool Sun Mail? Is it about Oracle
licensing and the now-required purchase and support cost?
Yes it is about cost mostly. We had Sun Mail for our Staff and students.
We had
20,000 + students on it up until Christmas time as well. We have now
migrated them
to M$ Live@EDU. This leaves us with 1500 Staff left who all like to use
LookOut. The Sun
connector for LookOut is a bit flaky at best. But the Oracle licensing
cost for Messaging
and Calendar starts at 10,000 users plus and so is now rather expensive
for what mailboxes
we have left. M$ also heavily discounts Exchange CALS to Edu and Oracle
is not very friendly
the way Sun was with their JES licensing. So it is bye bye Sun Messaging
Server for us.
2011-06-13 1:14, Scott Lawson пишет:
Hi All,
I have an interesting question that may or may not be answerable from
some internal
ZFS semantics.
I have a Sun Messaging Server which has 5 ZFS based email stores. The
Sun Messaging server
uses hard links to link identical messages together. Messages are
stored in standard SMTP
MIME format so the binary attachments are included in the message
ASCII. Each individual
message is stored in a separate file.
So as an example if a user sends a email with a 2MB attachment to the
staff mailing list and there
is 3 staff stores with 500 users on each, it will generate a space
usage like :
/store1 = 1 x 2MB + 499 x 1KB
/store2 = 1 x 2MB + 499 x 1KB
/store3 = 1 x 2MB + 499 x 1KB
So total storage used is around ~7.5MB due to the hard linking taking
place on each store.
If hard linking capability had been turned off, this same message
would have used 1500 x 2MB =3GB
worth of storage.
My question is there any simple ways of determining the space savings
on each of the stores from
the usage of hard links? The reason I ask is that our educational
institute wishes to migrate these stores
to M$ Exchange 2010 which doesn't do message single instancing. I
need to try and project what the storage
requirement will be on the new target environment.
If anyone has any ideas be it ZFS based or any useful scripts that
could help here, I am all ears.
I may post this to Sun Managers as well to see if anyone there might
have any ideas on this as well.
Regards,
Scott.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss