"Paul B. Henson" writes:
> Good :). I am certainly not wedded to my proposal, if some other
> solution is proposed that would meet my requirements, great. However,
> pretty much all of the advice has boiled down to either "ACL's are
> broken, don't use them", or "why would you want to do *that*?"
"Paul B. Henson" writes:
> On Tue, 2 Mar 2010, Kjetil Torgrim Homme wrote:
>
>> no. what happens when an NFS client without ACL support mounts your
>> filesystem? your security is blown wide open. the filemode should
>> reflect the *least* level of access.
Freddie Cash writes:
> Kjetil Torgrim Homme wrote:
>
> it would be inconvenient to make a dedup copy on harddisk or tape,
> you could only do it as a ZFS filesystem or ZFS send stream. it's
> better to use a generic tool like hardlink(1), and just delete
>
"valrh...@gmail.com" writes:
> I have been using DVDs for small backups here and there for a decade
> now, and have a huge pile of several hundred. They have a lot of
> overlapping content, so I was thinking of feeding the entire stack
> into some sort of DVD autoloader, which would just read eac
"Paul B. Henson" writes:
> On Sun, 28 Feb 2010, Kjetil Torgrim Homme wrote:
>
>> why are you doing this? it's inherently insecure to rely on ACL's to
>> restrict access. do as David says and use ACL's to *grant* access.
>> if needed, set permiss
"Paul B. Henson" writes:
> On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
>> I think of using ACLs to extend extra access beyond what the
>> permission bits grant. Are you talking about using them to prevent
>> things that the permission bits appear to grant? Because so long as
>> they're only gr
tomwaters writes:
> I created a zfs file system, cloud/movies and shared it.
> I then filled it with movies and music.
> I then decided to rename it, so I used rename in the Gnome to change
> the folder name to media...ie cloud/media. < MISTAKE
> I then noticed the zfs share was pointing to /
"David Dyer-Bennet" writes:
> Which is bad enough if you say "ls". And there's no option to say
> "don't sort" that I know of, either.
/bin/ls -f
"/bin/ls" makes sure an alias for "ls" to "ls -F" or similar doesn't
cause extra work. you can also write "\ls -f" to ignore a potential
alias.
wi
Steve writes:
> I would like to ask a question regarding ZFS performance overhead when
> having hundreds of millions of files
>
> We have a storage solution, where one of the datasets has a folder
> containing about 400 million files and folders (very small 1K files)
>
> What kind of overhead do
Miles Nordin writes:
>>>>>> "kth" == Kjetil Torgrim Homme writes:
>
>kth> the SCSI layer handles the replaying of operations after a
>kth> reboot or connection failure.
>
> how?
>
> I do not think it is handled by SCSI layers,
Miles Nordin writes:
> There will probably be clients that might seem to implicitly make this
> assuption by mishandling the case where an iSCSI target goes away and
> then comes back (but comes back less whatever writes were in its write
> cache). Handling that case for NFS was complicated, and
Chris Banal writes:
> We have a SunFire X4500 running Solaris 10U5 which does about 5-8k nfs
> ops of which about 90% are meta data. In hind sight it would have been
> significantly better to use a mirrored configuration but we opted for
> 4 x (9+2) raidz2 at the time. We can not take the downti
Bogdan Ćulibrk writes:
> What are my options from here? To move onto zvol with greater
> blocksize? 64k? 128k? Or I will get into another trouble going that
> way when I have small reads coming from domU (ext3 with default
> blocksize of 4k)?
yes, definitely. have you considered using NFS rathe
[please don't top-post, please remove CC's, please trim quotes. it's
really tedious to clean up your post to make it readable.]
Marc Nicholas writes:
> Brent Jones wrote:
>> Marc Nicholas wrote:
>>> Kjetil Torgrim Homme wrote:
>>>> his problem
Bob Friesenhahn writes:
> On Wed, 10 Feb 2010, Frank Cusack wrote:
>
> The other three commonly mentioned issues are:
>
> - Disable the naggle algorithm on the windows clients.
for iSCSI? shouldn't be necessary.
> - Set the volume block size so that it matches the client filesystem
>block
"Eric D. Mudama" writes:
> On Tue, Feb 9 at 2:36, Kjetil Torgrim Homme wrote:
>> no one is selling disk brackets without disks. not Dell, not EMC,
>> not NetApp, not IBM, not HP, not Fujitsu, ...
>
> http://discountechnology.com/Products/SCSI-Hard-Drive-C
Neil Perrin writes:
> On 02/09/10 08:18, Kjetil Torgrim Homme wrote:
>> I think the above is easily misunderstood. I assume the OP means
>> append, not rewrites, and in that case (with recordsize=128k):
>>
>> * after the first write, the file will consist of a sing
Richard Elling writes:
> On Feb 8, 2010, at 6:04 PM, Kjetil Torgrim Homme wrote:
>> the size of [a DDT] entry is much larger:
>>
>> | From: Mertol Ozyoney
>> |
>> | Approximately it's 150 bytes per individual block.
>
> "zdb -D poolname"
Richard Elling writes:
> On Feb 8, 2010, at 9:10 PM, Damon Atkins wrote:
>
>> I would have thought that if I write 1k then ZFS txg times out in
>> 30secs, then the 1k will be written to disk in a 1k record block, and
>> then if I write 4k then 30secs latter txg happen another 4k record
>> size bl
grarpamp writes:
> PS: Is there any way to get a copy of the list since inception for
> local client perusal, not via some online web interface?
I prefer to read mailing lists using a newsreader and the NNTP interface
at Gmane. a newsreader tends to be better at threading etc. than a mail
clien
Damon Atkins writes:
> One problem could be block sizes, if a file is re-written and is the
> same size it may have different ZFS record sizes within, if it was
> written over a long period of time (txg's)(ignoring compression), and
> therefore you could not use ZFS checksum to compare two files.
Tom Hall writes:
> If you enable it after data is on the filesystem, it will find the
> dupes on read as well as write? Would a scrub therefore make sure the
> DDT is fully populated.
no. only written data is added to the DDT, so you need to copy the data
somehow. zfs send/recv is the most con
Daniel Carosone writes:
> In that context, I haven't seen an answer, just a conclusion:
>
> - All else is not equal, so I give my money to some other hardware
>manufacturer, and get frustrated that Sun "won't let me" buy the
>parts I could use effectively and comfortably.
no one is s
Christo Kutrovsky writes:
> Has anyone seen soft corruption in NTFS iSCSI ZVOLs after a power
> loss?
this is not from experience, but I'll answer anyway.
> I mean, there is no guarantee writes will be executed in order, so in
> theory, one could corrupt it's NTFS file system.
I think you have
Tim Cook writes:
> Kjetil Torgrim Homme wrote:
>>I don't know what the J4500 drive sled contains, but for the J4200
>>and J4400 they need to include quite a bit of circuitry to handle
>>SAS protocol all the way, for multipathing and to be able to
>>
Darren J Moffat writes:
> That disables the ZIL for *all* datasets on *all* pools on the system.
> Doing this means that for NFS client or other applications (maybe
> local) that rely on the POSIX synchronus requirements of fsync they
> may see data loss on a crash. Note that the ZFS pool is sti
"Nilsen, Vidar" writes:
> And once an hour I run a script that checks for new dirs last 60
> minutes matching some criteria, and outputs the path to an
> IRC-channel. Where we can see if someone else has added new stuff.
>
> Method used is “find –mmin -60”, which gets horrible slow when more
> da
Frank Cusack writes:
> On 2/4/10 8:00 AM +0100 Tomas Ögren wrote:
>> The "find -newer blah" suggested in other posts won't catch newer
>> files with an old timestamp (which could happen for various reasons,
>> like being copied with kept timestamps from somewhere else).
>
> good point. that is d
matthew patton writes:
> true. but I buy a Ferrari for the engine and bodywork and chassis
> engineering. It is totally criminal what Sun/EMC/Dell/Netapp do
> charging customers 10x the open-market rate for standard drives. A
> RE3/4 or NS drive is the same damn thing no matter if I buy it from
>
Alexandre MOREL writes:
> It's a few day now that I try to use a 9650SE 3ware controller to work
> on opensolaris and I found the following problem : the tw driver seems
> work, I can see my controller whith the tw_cli of 3ware. I can see
> that 2 drives are created with the controller, but when
antst writes:
> I'm more than happy by the fact that data consumes even less physical
> space on storage. But I want to understand why and how. And want to
> know to what numbers I can trust.
my guess is sparse files.
BTW, I think you should compare the size returned from "du -bx" with
"refer"
Tiernan O'Toole writes:
> looking at the 3ware 9650 SE raid controller for a new build... anyone
> have any luck with this card? their site says they support
> OpenSolaris... anyone used one?
didn't work too well for me. it's fast and nice for a couple of days,
then the driver gets slower and s
Mark Bennett writes:
> Update:
>
> For the WD10EARS, the blocks appear to be aligned on the 4k boundary
> when zfs uses the whole disk (whole disk as EFI partition).
>
> Part TagFlag First Sector Size Last Sector
> 0usrwm256 931.51Gb
Freddie Cash writes:
> We use the following for our storage servers:
> [...]
> 3Ware 9650SE PCIe RAID controller (12-port, muli-lane)
> [...]
> Fully supported by FreeBSD, so everything should work with
> OpenSolaris.
FWIW, I've used the 9650SE with 16 ports in OpenSolaris 2008.11 and
2009.06, a
Mike Gerdts writes:
> Kjetil Torgrim Homme wrote:
>> Mike Gerdts writes:
>>
>>> John Hoogerdijk wrote:
>>>> Is there a way to zero out unused blocks in a pool? I'm looking for
>>>> ways to shrink the size of an opensolaris virtualbox VM and
Mike Gerdts writes:
> John Hoogerdijk wrote:
>> Is there a way to zero out unused blocks in a pool? I'm looking for
>> ways to shrink the size of an opensolaris virtualbox VM and using the
>> compact subcommand will remove zero'd sectors.
>
> I've long suspected that you should be able to just u
David Magda writes:
> On Jan 24, 2010, at 10:26, Kjetil Torgrim Homme wrote:
>
>> But it occured to me that this is a special case which could be
>> beneficial in many cases -- if the filesystem uses secure checksums,
>> it could check the existing block pointer and see
Tim Cook writes:
> On Sat, Jan 23, 2010 at 7:57 PM, Frank Cusack wrote:
>
> I mean, just do a triple mirror of the 1.5TB drives rather than
> say (6) .5TB drives in a raidz3.
>
> I bet you'll get the same performance out of 3x1.5TB drives you get
> out of 6x500GB drives too.
no, it will
I was looking at the performance of using rsync to copy some large files
which change only a little between each run (database files). I take a
snapshot after every successful run of rsync, so when using rsync
--inplace, only changed portions of the file will occupy new disk space.
Unfortunately,
Lutz Schumann writes:
> Actually the performance decrease when disableing the write cache on
> the SSD is aprox 3x (aka 66%).
for this reason, you want a controller with battery backed write cache.
in practice this means a RAID controller, even if you don't use the RAID
functionality. of course
Brad writes:
> Hi Adam,
I'm not Adam, but I'll take a stab at it anyway.
BTW, your crossposting is a bit confusing to follow, at least when using
gmane.org. I think it is better to stick to one mailing list anyway?
> From your the picture, it looks like the data is distributed evenly
> (with
Anil writes:
> If you have another partition with enough space, you could technically
> just do:
>
> mv src /some/other/place
> mv /some/other/place src
>
> Anyone see a problem with that? Might be the best way to get it
> de-duped.
I get uneasy whenever I see mv(1) used to move directory trees
Darren J Moffat writes:
> Kjetil Torgrim Homme wrote:
>
>> I don't know how tightly interwoven the dedup hash tree and the block
>> pointer hash tree are, or if it is all possible to disentangle them.
>
> At the moment I'd say very interwoven by design.
Darren J Moffat writes:
> Kjetil Torgrim Homme wrote:
>> Andrey Kuzmin writes:
>>
>>> Downside you have described happens only when the same checksum is
>>> used for data protection and duplicate detection. This implies sha256,
>>> BTW, since fletch
Andrey Kuzmin writes:
> Downside you have described happens only when the same checksum is
> used for data protection and duplicate detection. This implies sha256,
> BTW, since fletcher-based dedupe has been dropped in recent builds.
if the hash used for dedup is completely separate from the has
Andrey Kuzmin writes:
> Darren J Moffat wrote:
>> Andrey Kuzmin wrote:
>>> Resilvering has noting to do with sha256: one could resilver long
>>> before dedupe was introduced in zfs.
>>
>> SHA256 isn't just used for dedup it is available as one of the
>> checksum algorithms right back to pool versi
Andrey Kuzmin writes:
> Yet again, I don't see how RAID-Z reconstruction is related to the
> subject discussed (what data should be sha256'ed when both dedupe and
> compression are enabled, raw or compressed ). sha256 has nothing to do
> with bad block detection (may be it will when encryption is
Andrey Kuzmin writes:
> Kjetil Torgrim Homme wrote:
>> for some reason I, like Steve, thought the checksum was calculated on
>> the uncompressed data, but a look in the source confirms you're right,
>> of course.
>>
>> thinking about the consequences of
Robert Milkowski writes:
> On 13/12/2009 20:51, Steve Radich, BitShop, Inc. wrote:
>> Because if you can de-dup anyway why bother to compress THEN check?
>> This SEEMS to be the behaviour - i.e. I would suspect many of the
>> files I'm writing are dups - however I see high cpu use even though
>> o
Brandon High writes:
> Matthew Ahrens wrote:
>> Well, changing the "compression" property doesn't really interrupt
>> service, but I can understand not wanting to have even a few blocks
>> with the "wrong"
>
> I was thinking of sharesmb or sharenfs settings when I wrote that.
> Toggling them for
Adam Leventhal writes:
> Unfortunately, dedup will only apply to data written after the setting
> is enabled. That also means that new blocks cannot dedup against old
> block regardless of how they were written. There is therefore no way
> to "prepare" your pool for dedup -- you just have to enabl
I'm planning to try out deduplication in the near future, but started
wondering if I can prepare for it on my servers. one thing which struck
me was that I should change the checksum algorithm to sha256 as soon as
possible. but I wonder -- is that sufficient? will the dedup code know
about old b
Daniel Carosone writes:
>>> Not if you're trying to make a single disk pool redundant by adding
>>> .. er, attaching .. a mirror; then there won't be such a warning,
>>> however effective that warning might or might not be otherwise.
>>
>> Not a problem because you can then detach the vdev and a
I was catching up on old e-mail on this list, and came across a blog
posting from Henrik Johansson:
http://sparcv9.blogspot.com/2009/10/curious-case-of-strange-arc.html
it tells of his woes with a fragmented /var/pkg/downloads combined
with atime updates. I see the same problem on my servers,
Daniel Carosone writes:
>> you can fetch the "cr_txg" (cr for creation) for a
>> snapshot using zdb,
>
> yes, but this is hardly an appropriate interface.
agreed.
> zdb is also likely to cause disk activity because it looks at many
> things other than the specific item in question.
I'd expect
Daniel Carosone writes:
>> I don't think it is easy to do, the txg counter is on
>> a pool level,
>> [..]
>> it would help when the entire pool is idle, though.
>
> .. which is exactly the scenario in question: when the disks are
> likely to be spun down already (or to spin down soon without furt
sundeep dhall writes:
> Q) How do I simulate a sudden 1-disk failure to validate that zfs /
> raidz handles things well without data errors
>
> Options considered
> 1. suddenly pulling a disk out
> 2. using zpool offline
>
> I think both these have issues in simulating a sudden failure
why not
Daniel Carosone writes:
> Would there be a way to avoid taking snapshots if they're going to be
> zero-sized?
I don't think it is easy to do, the txg counter is on a pool level,
AFAIK:
# zdb -u spool
Uberblock
magic = 00bab10c
version = 13
txg = 1773324
Kjetil Torgrim Homme writes:
> Cindy Swearingen writes:
>> You might check the slides on this page:
>>
>> http://hub.opensolaris.org/bin/view/Community+Group+zfs/docs
>>
>> Particularly, slides 14-18.
>>
>> In this case, graphic illustrations are prob
Darren J Moffat writes:
> Mauricio Tavares wrote:
>> If I have a machine with two drives, could I create equal size slices
>> on the two disks, set them up as boot pool (mirror) and then use the
>> remaining space as a striped pool for other more wasteful
>> applications?
>
> You could but why bo
Cindy Swearingen writes:
> I wish we had a zpool destroy option like this:
>
> # zpool destroy -really_dead tank2
I think it would be clearer to call it
zpool export --clear-name tank # or 3280066346390919920
or alternatively,
zpool destroy --exported 3280066346390919920
I guess the rea
"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
"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 comp
"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
Roman V Shaposhnik writes:
> I must admit that this question originates in the context of Sun's
> Storage 7210 product, which impose additional restrictions on the
> kind of knobs I can turn.
>
> But here's the question: suppose I have an installation where ZFS is
> the storage for user home dire
Frank Middleton writes:
> Exactly. My whole point. And without ECC there's no way of knowing.
> But if the data is damaged /after/ checksum but /before/ write, then
> you have a real problem...
we can't do much to protect ourselves from damage to the data itself
(an extra copy in RAM will help l
66 matches
Mail list logo
