Bob Friesenhahn wrote:
On Wed, 17 Jun 2009, Haudy Kazemi wrote:
usable with very little CPU consumed.
If the system is dedicated to serving files rather than also being
used interactively, it should not matter much what the CPU usage is.
CPU cycles can't be stored for later use. Ultimately,
On Thu, Jun 18, 2009 at 10:56 AM, Dave Ringkor wrote:
> But what if I used zfs send to save a recursive snapshot of my root pool on
> the old server, booted my new server (with the same architecture) from the
> DVD in single user mode and created a ZFS pool on its local disks, and did
> zfs rece
> This is a mysql database server, so if you are wondering about the
> smallish arc size, it's being artificially limited by "set
> zfs:zfs_arc_max = 0x8000" in /etc/system, so that the majority of
> ram can be allocated to InnoDb.
>
I was told offline that it's likely because my arc size ha
Den 18 juni 2009 06.47 skrev Timh Bergström:
> The way I see it is that eventhough ZFS may be a wonderful filesystem,
> it is not the best solution for every possible (odd) setup. I.e
> USB-sticks has proven a bad idea with zfs mirrors, ergo - dont do
> it(tm).
>
> ZFS on iSCSI *is* flaky and a hos
The way I see it is that eventhough ZFS may be a wonderful filesystem,
it is not the best solution for every possible (odd) setup. I.e
USB-sticks has proven a bad idea with zfs mirrors, ergo - dont do
it(tm).
ZFS on iSCSI *is* flaky and a host-reboot without telling the target
will most likely get
Hi all,
Since we've started running 2009.06 on a few servers we seem to be
hitting a problem with l2arc that causes it to stop receiving evicted
arc pages. Has anyone else seen this kind of problem?
The filesystem contains about 130G of compressed (lzjb) data, and looks
like:
$ zpool status -v d
So I had an E450 running Solaris 8 with VxVM encapsulated root disk. I
upgraded it to Solaris 10 ZFS root using this method:
- Unencapsulate the root disk
- Remove VxVM components from the second disk
- Live Upgrade from 8 to 10 on the now-unused second disk
- Boot to the new Solaris 10 install
On Wed, 17 Jun 2009, Haudy Kazemi wrote:
usable with very little CPU consumed.
If the system is dedicated to serving files rather than also being used
interactively, it should not matter much what the CPU usage is. CPU cycles
can't be stored for later use. Ultimately, it (mostly*) does not ma
On Thu 18/06/09 09:42 , Miles Nordin car...@ivy.net sent:
> Access to the bug database is controlled.
No, the bug databse is open.
Ian.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Thu, Jun 18, 2009 at 6:42 AM, Miles Nordin wrote:
> Surely you can understand there is such thing as a ``hard to reproduce
> problem?'' Is the phrase so new to you? If you'd experience with
> other filesystems in their corruption-prone infancy, it wouldn't be.
I understand your point, but I d
I have Ubuntu jaunty already installed on my pc, on the second HD, i've
installed OS2009
Now, i cant share info between this 2 OS.
I download and install ZFS-FUSE on jaunty, but the version is 6, instead in
OS209 the ZFS version is 14 or something else.
off course, thera are different versions.
H
David Magda wrote:
On Tue, June 16, 2009 15:32, Kyle McDonald wrote:
So the cache saves not only the time to access the disk but also the CPU
time to decompress. Given this, I think it could be a big win.
Unless you're in GIMP working on JPEGs, or doing some kind of MPEG video
editing
On 17-Jun-09, at 5:42 PM, Miles Nordin wrote:
"bmm" == Bogdan M Maryniuk writes:
"tt" == Toby Thain writes:
"ok" == Orvar Korvar writes:
tt> Slashdot was never the place to go for accurate information
tt> about ZFS.
again, the posts in the slashdot thread complaining about corrupt
Bob Friesenhahn wrote:
On Mon, 15 Jun 2009, Bob Friesenhahn wrote:
On Mon, 15 Jun 2009, Rich Teer wrote:
You actually have that backwards. :-) In most cases, compression is
very
desirable. Performance studies have shown that today's CPUs can
compress
data fast
great, will try it tomorrow!
thanks very much!
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> "bmm" == Bogdan M Maryniuk writes:
> "tt" == Toby Thain writes:
> "ok" == Orvar Korvar writes:
bmm> Personally I am running various open solaris versions on a
bmm> VirtualBox as a crash dummy, as well as running osol on a real
bmm> systems. All ZFS.
It sounds like what y
> "djm" == Darren J Moffat writes:
> "cd" == Casper Dik writes:
djm> http://opensolaris.org/os/project/osarm/
yeah. many of those ARM systems will be low-power
builtin-crypto-accel builtin-gigabit-MAC based on Orion and similar,
NAS (NSLU2-ish) things begging for ZFS.
cd> It's
Hi UNIX admin,
I would check fmdump -eV output to see if this error is isolated or
persistent.
If fmdump says this error is isolated, then you might just monitor the
status. For example, if fmdump says that these errors occurred on 6/15
and you moved this system on that date or you know that som
pool: space01
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the dev
Hi Roland,
Current Solaris releases, SXCE (build 98) or OpenSolaris 2009.06,
provide space accounting features to display space consumed by
snapshots, descendent datasets, and so on.
On my OSOL 2009.06 system with automatic snapshots running, I can see
the space that is consumed by snapshots by
Dirk Nitschke wrote:
> Solaris /usr/bin/find and Linux (GNU-) find work differently! I have
> experienced dramatic runtime differences some time ago. The reason is
> that Solaris find and GNU find use different algorithms.
Correct: Solaris find honors the POSIX standard, GNU find does not :-
roland wrote:
Solaris is NOT a super-duper-plays-in-all-possible-spaces OS.
yes, i know - but it`s disappointing that not even 32bit and 64bit x86 hardware
is handled the same.
1TB limit on 32bit, less stable on 32bit.
sorry, but if you are used to linux, solaris is really weird.
issue
>Hi Louis!
>
>Solaris /usr/bin/find and Linux (GNU-) find work differently! I have
>experienced dramatic runtime differences some time ago. The reason is
>that Solaris find and GNU find use different algorithms.
>
>GNU find uses the st_nlink ("number of links") field of the stat
>structure t
hello,
i`m doing backups to several backup-dirs where each is a sub-filesystem on
/zfs, i.e. /zfs/backup1 , /zfs/backup2
i do snapshots on daily base, but have a problem:
how can i see, how much space is in use by the snapshots for each sub-fs, i.e.
i want to see what`s being in use on /zfs/ba
>Solaris is NOT a super-duper-plays-in-all-possible-spaces OS.
yes, i know - but it`s disappointing that not even 32bit and 64bit x86 hardware
is handled the same.
1TB limit on 32bit, less stable on 32bit.
sorry, but if you are used to linux, solaris is really weird.
issue here, limitation ther
Hi Louis!
Solaris /usr/bin/find and Linux (GNU-) find work differently! I have
experienced dramatic runtime differences some time ago. The reason is
that Solaris find and GNU find use different algorithms.
GNU find uses the st_nlink ("number of links") field of the stat
structure to optim
On Wed, June 17, 2009 06:15, Fajar A. Nugraha wrote:
>>> Perhaps compressing /usr could be handy, but why bother enabling
>>> compression if the majority (by volume) of user data won't do
>>> anything but burn CPU?
>
> How do you define "substantial"? My opensolaris snv_111b installation
> has 1.4
On Wed, June 17, 2009 06:03, Kjetil Torgrim Homme wrote:
> I'd be interested to see benchmarks on MySQL/PostgreSQL performance
> with compression enabled. my *guess* would be it isn't beneficial
> since they usually do small reads and writes, and there is little gain
> in reading 4 KiB instead of
Jose,
I believe the problem is endemic to Solaris. I have run into similar
problems doing a simple find(1) in /etc. On Linux, a find operation in
/etc is almost instantaneous. On solaris, it has a tendency to spin
for a long time. I don't know what their use of find might be but,
running
On Wed, Jun 17 at 13:49, Alan Hargreaves wrote:
Another question worth asking here is, is a find over the entire
filesystem something that they would expect to be executed with
sufficient regularity that it the execution time would have a business
impact.
Exactly. That's such an odd busin
Harry Putnam writes:
> cindy.swearin...@sun.com writes:
>
> [...]
>> # zfs list -rt snapshot z3/www
> [...]
> Yeah... now were talking thanks
>
> I'm still a little curious though as to why
> `zfs list -t snapshot'
>
> By itself without a dataset, only lists snapshots under z3/www
>
> I un
cindy.swearin...@sun.com writes:
[...]
>
> # zfs list -rt snapshot z3/www
[...]
Yeah... now were talking thanks
I'm still a little curious though as to why
`zfs list -t snapshot'
By itself without a dataset, only lists snapshots under z3/www
I understand about the `-r recursive' but w
On 17-Jun-09, at 7:37 AM, Orvar Korvar wrote:
Ok, so you mean the comments are mostly FUD and bull shit? Because
there are no bug reports from the whiners? Could this be the case?
It is mostly FUD? Hmmm...?
Having read the thread, I would say "without a doubt".
Slashdot was never the pl
Jose,
I hope our openstorage experts weigh in on 'is this a good idea', it
sounds scary to me but I'm
overly cautious anyway. I did want to raise the question of other
client expectations for this
opportunity, what are the intended data protection requirements, how will
they backup and reco
On Tue, Jun 16, 2009 at 6:46 PM, T Johnson wrote:
> Is there a problem with moving drives from one controller to another that
> my googlefu is not turning up?
>
> I had a system with it's boot drive attached to a backplane which worked
> fine. I tried moving that drive to the onboard controller a
On Wed, Jun 17, 2009 at 8:37 PM, Orvar Korvar wrote:
> Ok, so you mean the comments are mostly FUD and bull shit?
Unless there is real step-by-step reproducible proof, then yes, it is
completely useless waste of time and BS that I would not care at all,
if I were you.
--
Kind regards, BM
Things
> > 32 bit Solaris can use at most 2^31 as disk address; a disk block is
> > 512bytes, so in total it can address 2^40 bytes.
> >
> > A SMI label found in Solaris 10 (update 8?) and OpenSolaris has been
> > enhanced
> > and can address 2TB but only on a 64 bit system.
>
> is what the problem is.
"Monish Shah" writes:
>> I'd be interested to see benchmarks on MySQL/PostgreSQL performance
>> with compression enabled. my *guess* would be it isn't beneficial
>> since they usually do small reads and writes, and there is little
>> gain in reading 4 KiB instead of 8 KiB.
>
> OK, now you have s
thank you, caspar.
to sum up here (seems to have been a lot of confusion in this thread):
the efi vs. smi thing that richard and a few other people have talked
about is not the issue at the heart of this. this:
> 32 bit Solaris can use at most 2^31 as disk address; a disk block is
> 512bytes, so
Unless you're in GIMP working on JPEGs, or doing some kind of MPEG
video editing--or ripping audio (MP3 / AAC / FLAC) stuff. All of
which are probably some of the largest files in most people's
homedirs nowadays.
indeed. I think only programmers will see any substantial benefit
from compression
Ok, so you mean the comments are mostly FUD and bull shit? Because there are no
bug reports from the whiners? Could this be the case? It is mostly FUD? Hmmm...?
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensol
"Fajar A. Nugraha" writes:
> Kjetil Torgrim Homme wrote:
>> indeed. I think only programmers will see any substantial benefit
>> from compression, since both the code itself and the object files
>> generated are easily compressible.
>
>>> Perhaps compressing /usr could be handy, but why bother e
>On Wed, Jun 17, 2009 at 5:03 PM, Kjetil Torgrim Homme.no> wrote:
>> indeed. =A0I think only programmers will see any substantial benefi=
>t
>> from compression, since both the code itself and the object files
>> generated are easily compressible.
>
>>> Perhaps compressing /usr could be handy, but
Le 16 juin 09 à 19:55, Jose Martins a écrit :
Hello experts,
IHAC that wants to put more than 250 Million files on a single
mountpoint (in a directory tree with no more than 100 files on each
directory).
He wants to share such filesystem by NFS and mount it through
many Linux Debian clients
On Wed, Jun 17, 2009 at 5:03 PM, Kjetil Torgrim Homme wrote:
> indeed. I think only programmers will see any substantial benefit
> from compression, since both the code itself and the object files
> generated are easily compressible.
>> Perhaps compressing /usr could be handy, but why bother enab
Erik Trimble wrote:
Dennis is correct in that there are significant areas where 32-bit
systems will remain the norm for some time to come. And choosing a
32-bit system in these areas is completely correct.
That said, I think the issue is that (unlike Linux), Solaris is NOT a
super-duper-plays
"David Magda" writes:
> On Tue, June 16, 2009 15:32, Kyle McDonald wrote:
>
>> So the cache saves not only the time to access the disk but also
>> the CPU time to decompress. Given this, I think it could be a big
>> win.
>
> Unless you're in GIMP working on JPEGs, or doing some kind of MPEG
> vid
> I had a system with it's boot drive
> attached to a backplane which worked fine. I tried
> moving that drive to the onboard controller and a few
> seconds into booting it would just reboot.
In certain cases zfs is able to find the drive on the
new physical device path (IIRC: the disk's "devid"
>> Not a ZFS bug. IIRC, the story goes something like this: a SMI
>> label only works to 1 TByte, so to use > 1 TByte, you need an
>> EFI label. For older x86 systems -- those which are 32-bit -- you
>> probably have a BIOS which does not handle EFI labels. This
>> will become increasingly irr
casper@sun.com wrote:
> >ie, I can have >1Tb disks as part of a non-bootable data pool, with EFI
> >labels, on a 32-bit machine?
>
> No; the daddr_t is only 32 bits.
This looks like a left over problem problem from former times when UFS was
limited to 1 TB anyway.
Jörg
--
EMail:jo...@sc
> Not a ZFS bug. IIRC, the story goes something like this: a SMI
> label only works to 1 TByte, so to use > 1 TByte, you need an
> EFI label. For older x86 systems -- those which are 32-bit -- you
> probably have a BIOS which does not handle EFI labels. This
> will become increasingly irritatin
Hello Richard,
Monish Shah wrote:
What about when the compression is performed in dedicated hardware?
Shouldn't compression be on by default in that case? How do I put in an
RFE for that?
Is there a bugs.intel.com? :-)
I may have misled you. I'm not asking for Intel to add hardware
comp
casper@sun.com wrote:
It's true for most of the Intel Atom family (Zxxx and Nxxx but not the
230 and 330 as those are 64 bit) Those are new systems.
Casper
___
I've actually just started to build my home raid using the Atom 330
(D945GCLF2):
>> Not a ZFS bug. [SMI vs EFI labels vs BIOS booting]
>
>and so also only a problem for disks that are members of the root pool.
>
>ie, I can have >1Tb disks as part of a non-bootable data pool, with EFI
>labels, on a 32-bit machine?
No; the daddr_t is only 32 bits.
Casper
_
>$ psrinfo -pv
>The physical processor has 1 virtual processor (0)
> x86 (CentaurHauls 6A9 family 6 model 10 step 9 clock 1200 MHz)
>VIA Esther processor 1200MHz
>
>Also, some of the very very small little PC units out there, those things
>called eePC ( or whatever ) are probably 32-bit
>roland wrote:
>> so, we have a 128bit fs, but only support for 1tb on 32bit?
>>
>> i`d call that a bug, isn`t it ? is there a bugid for this? ;)
>>
>
>Not a ZFS bug. IIRC, the story goes something like this: a SMI
>label only works to 1 TByte, so to use > 1 TByte, you need an
>EFI label. Fo
56 matches
Mail list logo