On Wed, Jun 07, 2006 at 07:21:18PM -0400, Bill Sommerfeld wrote:
> On Wed, 2006-06-07 at 19:08, Nicolas Williams wrote:
> > There's no incremental index maintenance to do as views would be like
> > snapshots, so once a view is computed for one directory it could be
> > cached, possibly persistently
On Wed, 2006-06-07 at 19:08, Nicolas Williams wrote:
> There's no incremental index maintenance to do as views would be like
> snapshots, so once a view is computed for one directory it could be
> cached, possibly persistently, so that the next time the readdir doesn't
> have to stat all the files
On Wed, Jun 07, 2006 at 06:48:01PM -0400, Bill Sommerfeld wrote:
> On Wed, 2006-06-07 at 17:31, Nicolas Williams wrote:
> > Views would be faster, initially (they could be O(1) to create),
>
> if you're not incrementally maintaining indexes, and you want O(1)
> creation and O(D) readdir (where D
On Wed, 2006-06-07 at 17:31, Nicolas Williams wrote:
> Views would be faster, initially (they could be O(1) to create),
if you're not incrementally maintaining indexes, and you want O(1)
creation and O(D) readdir (where D is the size of the directory) of
directories, I don't think you'll be able
Henk,
I think Alec was being sarcastic. :-P
And, Alec - that wasn't a good example. That was Windows Explorer (under
XP and later) which presented ZIP files as browsable folders, not NTFS.
We do need to be careful to differentiate between GUI and CLI _viewing_
of the filesystem, and the actual
Alec suggested file system "views" and Andreas questioned:
How is it different from creating a snapshot and running "find" on it?
More convenient? Faster? Something else?
To which Alec responded:
Ever encountered an operating system that allows you
to mount and manipulate a ZIP file as a files
>How is it different from creating a snapshot and running "find" on it?
>More convenient? Faster? Something else?
Ever encountered an operating system that allows you
to mount and manipulate a ZIP file as a filesystem?
Why did anyone bother to do that, when they could just
"zip -l" and pipe t
On Wed, Jun 07, 2006 at 02:06:23PM -0700, Andreas Sterbenz wrote:
> Alec Muffett wrote:
> >
> >...etc, etc, you can guess the extra sorts of tests to make. Go read
> >the manpage for "find" for inspiration.
>
> How is it different from creating a snapshot and running "find" on it?
> More conveni
Alec Muffett wrote:
...etc, etc, you can guess the extra sorts of tests to make. Go read
the manpage for "find" for inspiration.
How is it different from creating a snapshot and running "find" on it?
More convenient? Faster? Something else?
Andreas.
___
On Wed, Jun 07, 2006 at 11:28:28AM -0700, Philip Brown wrote:
> Nicolas Williams wrote:
> >On Wed, Jun 07, 2006 at 11:15:43AM -0700, Philip Brown wrote:
> >>This to me sounds much much better. Put all the funky potentially
> >>disasterous code, in lofs, not in zfs please :-) plus that way any
> >
Nicolas Williams wrote:
On Wed, Jun 07, 2006 at 11:15:43AM -0700, Philip Brown wrote:
Also, why shouldn't lofs grow similar support?
aha!
This to me sounds much much better. Put all the funky potentially
disasterous code, in lofs, not in zfs please :-) plus that way any
filesystem will pote
On Wed, Jun 07, 2006 at 11:15:43AM -0700, Philip Brown wrote:
> >Also, why shouldn't lofs grow similar support?
>
> aha!
> This to me sounds much much better. Put all the funky potentially
> disasterous code, in lofs, not in zfs please :-) plus that way any
> filesystem will potentially get the
Nicolas Williams wrote:
...
Also, why shouldn't lofs grow similar support?
aha!
This to me sounds much much better. Put all the funky potentially
disasterous code, in lofs, not in zfs please :-) plus that way any
filesystem will potentially get the "benefit" of views.
__
On Wed, Jun 07, 2006 at 04:15:04PM +0100, Alec Muffett wrote:
>
> >Should it retain the directory structure for each match, e.g.
> >~/.zfs/view/[EMAIL PROTECTED]/Music/A/Abba.mp3, or remap everything, e.g.
> >~/.zfs/view/[EMAIL PROTECTED]/Abba.mp3?
>
> The former; my intent was to compute the
I'm asking only for curiosity. I would like to know more about ZFS internals
espacially comparing Raid-Z to Raid-5 and improving applications to cooperation
with them. It isn't complaining on performance :)
This message posted from opensolaris.org
_
On Wed, Jun 07, 2006 at 07:10:56AM -0700, Andrzej Butkiewicz wrote:
> I suppose that could be work on this way: zfs receive a command to
> write part of the block, e.g. last 8kB in 32kB block. Next, instead
> that read-modify-write we write modify information into the cache and
> wait for next modi
Alec Muffett wrote:
Back to the matter at hand: would/should "views" be static / frozen
in time like a snapshot (presumably therefore computationally cheap
to create) - or should they be dynamic like a SQL view?
both types please, I can see uses for both of them, though with the
music example
>Insert mental image of Alec with headphones on, iPod in hand, singing
>"Dancing Queen" ... :-D
Tough Guys Don't Dance. More pointedly, I tend to fatally tread on
people and/ or destroy things. I need a folk festival, a field, and
serious amounts of ale to really get going. 8-)
Back to the
Martin Englund wrote:
Alec Muffett wrote:
Then you could "cd ~/.zfs/view/[EMAIL PROTECTED]" and see all your music
files. Or large files. Or files with nlinks>1. Or whatever.
Should it retain the directory structure for each match, e.g.
~/.zfs/view/[EMAIL PROTECTED]/Music/A/Abba.m
>Should it retain the directory structure for each match, e.g.
>~/.zfs/view/[EMAIL PROTECTED]/Music/A/Abba.mp3, or remap everything, e.g.
>~/.zfs/view/[EMAIL PROTECTED]/Abba.mp3?
The former; my intent was to compute the subset of filesystem objects
which match the patterns specified, and then
Alec Muffett wrote:
> Then you could "cd ~/.zfs/view/[EMAIL PROTECTED]" and see all your music
> files. Or large files. Or files with nlinks>1. Or whatever.
>
Should it retain the directory structure for each match, e.g.
~/.zfs/view/[EMAIL PROTECTED]/Music/A/Abba.mp3, or remap everything, e.g
On Wed, 2006-06-07 at 15:38 +0100, Alec Muffett wrote:
> The rough idea is something like a snapshot-with-selection-filters,
> perhaps made directly, or perhaps bred from an existing full-fat
> snapshot in a analogous way to clones.
Yep, I'd like 'em too - they would make the snapshot-GUI stuff I
Darren Moffat and I were having lunch and bouncing around ideas, and
I came up with the concept of "views" which neither of us are aware of
anyone having previously proposed.
The rough idea is something like a snapshot-with-selection-filters,
perhaps made directly, or perhaps bred from an existi
Andrzej Butkiewicz wrote:
Thanks Mark!
I see that writing part of filesystem block reduces performance. Especially in
Raid-Z because we have to read all spread on every disk blocks. Does ZFS have
any kind of blocks aggregation?
I suppose that could be work on this way: zfs receive a command t
Thanks Mark!
I see that writing part of filesystem block reduces performance. Especially in
Raid-Z because we have to read all spread on every disk blocks. Does ZFS have
any kind of blocks aggregation?
I suppose that could be work on this way: zfs receive a command to write part
of the block,
Hello zfs-discuss,
snv_39, SPARC, several raidz groups.
System panicked (due to my fault) and after reboot it was booting up
for about 10 minutes - I'm 99.9% sure it was "hung" in zfs importing
its pools. I have noticed such zfs behavior before and I it was
supposed to be corrected AFAIK
26 matches
Mail list logo
