Can some one here explain why accessing a NFSv4/ZFS xattr directory
through proc is forbidden?
To explain the problem in shell code (cd -@ is a new option to enter
the XATTR store, redirect {n}<... opens a file or directory and
assigns the fd number to variable 'n'):
ksh -c 'touch x ; cd -@ x ; re
On Thu, Jul 12, 2012 at 7:32 PM, Bob Friesenhahn
wrote:
> On Thu, 12 Jul 2012, bofh wrote:
>> When I do a snapshot, that file is part of the snapshot. But are
>> changes within the file kept as well?
>
> Only the difference (at block level) between the snapshots is kept. If the
> changed data was
On Thu, 12 Jul 2012, bofh wrote:
When I do a snapshot, that file is part of the snapshot. But are
changes within the file kept as well?
Only the difference (at block level) between the snapshots is kept.
If the changed data was changed 1000 times between the snapshots, then
only the differe
When I do a snapshot, that file is part of the snapshot. But are
changes within the file kept as well?
In other words, is it useful to have snapshots of a postgresql
database server? If a database file uses 10% of the pool, and changes
20% between each snapshot, would the pool run out of space a
On 07/12/2012 09:52 PM, Sašo Kiselkov wrote:
> I have far too much time to explain
P.S. that should have read "I have taken far too much time explaining".
Men are crap at multitasking...
Cheers,
--
Saso
___
zfs-discuss mailing list
zfs-discuss@opensolar
On 07/12/2012 07:16 PM, Tim Cook wrote:
> Sasso: yes, it's absolutely worth implementing a higher performing hashing
> algorithm. I'd suggest simply ignoring the people that aren't willing to
> acknowledge basic mathematics rather than lashing out. No point in feeding
> the trolls. The PETABYTES
Hi Rich,
I don't think anyone can say definitively how this problem resolved,
but I believe that the dd command overwrote some of the disk label,
as you describe below.
Your format output below looks like you relabeled the disk and maybe
that was enough to resolve this problem.
I have had succe
On Thu, Jul 12, 2012 at 9:14 AM, Edward Ned Harvey <
opensolarisisdeadlongliveopensola...@nedharvey.com> wrote:
> > From: Jim Klimov [mailto:jimkli...@cos.ru]
> > Sent: Thursday, July 12, 2012 8:42 AM
> > To: Edward Ned Harvey
> > Subject: Re: [zfs-discuss] New fast hash algorithm - is it needed?
>How did you decide it is okay and that zfs saved you? Did you
>NOT post some further progress in your recovery?
I made no further recovery attempts, the pool imported cleanly after
rebooting, or so i thought [1] as a zpool status showed no errors and i
could read data from the drive again.
On
> From: Jim Klimov [mailto:jimkli...@cos.ru]
> Sent: Thursday, July 12, 2012 8:42 AM
> To: Edward Ned Harvey
> Subject: Re: [zfs-discuss] New fast hash algorithm - is it needed?
>
> 2012-07-11 18:03, Edward Ned Harvey пишет:
> >> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> >>
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Sašo Kiselkov
>
> This is so profoundly wrong that it leads me to suspect you never took
> courses on cryptography and/or information theory.
More inflammatory commentary, and personal commen
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Nico Williams
>
> IMO dedup should always verify.
IMO, it should be a decision left to the user or admin, with the default being
verify. (Exactly as it is now.) Because there is a performan
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Sašo Kiselkov
>
> On 07/11/2012 05:58 PM, Gregg Wonderly wrote:
> > You're entirely sure that there could never be two different blocks that
can
> hash to the same value and have different cont
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
>
> Purely speculating, I might however suggest that your disk was
> dedicated to the pool completely, so its last blocks contain
> spare uberblocks (zpool labels) and that might hel
2012-07-12 14:20, RichTea wrote:
I meant to use dd to copy an image (around 500Mb) to a USB disk but
instead wrote over a non raided zfs disk!
Below is various status output's: My question is how after a reboot did
the disk / zpool recover with from what I have seen so far no corruption
at all
Hi All,
I hope this is the correct place for this question as I think it was ZFS
that saved me.
A little while ago I did some thing very silly in a moment of non
concentration...
I meant to use dd to copy an image (around 500Mb) to a USB disk but instead
wrote over a non raided zfs disk!
This of
16 matches
Mail list logo
