> What was the reason to make ZFS use directory sizes as the number of
> entries rather than the way other Unix filesystems use it?
In UFS, the st_size is the size of the directory inode as though it
were a file. The only reason it's like that is that UFS is sloppy
and lets you cat directories --
Thanks Darren, but the snapshot taken at 4 would be the snapshot on the storage
and not on the host so the storage system wouldnt really have to bother about
flushing the host FS or about consistency...which would be more a function of
the host FS or app?.
This message posted from opensolari
On Sat, Jun 09, 2007 at 02:01:35PM -0700, Eric Schrock wrote:
> On Sat, Jun 09, 2007 at 01:56:35PM -0700, Ed Ravin wrote:
> >
> > I encountered the problem in NetBSD's scandir(), when reading off
> > a Solaris NFS fileserver with ZFS filesystems. I've already filed a
> > bug report with NetBSD.
On Sat, Jun 09, 2007 at 01:56:35PM -0700, Ed Ravin wrote:
>
> I encountered the problem in NetBSD's scandir(), when reading off
> a Solaris NFS fileserver with ZFS filesystems. I've already filed a
> bug report with NetBSD. They were using the st_size, divided by 24, to
> determine how much memo
On Sat, Jun 09, 2007 at 10:16:34PM +0200, [EMAIL PROTECTED] wrote:
>
> >Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in
> >ZFS. Any word on when the fix will be out?
>
> It's a bug in scandir (obviously) and it is filed as such.
>
> Does scandir fail on zfs because of this o
[EMAIL PROTECTED] wrote:
>
> >Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in
> >ZFS. Any word on when the fix will be out?
>
> It's a bug in scandir (obviously) and it is filed as such.
A very old bug. I fixed it for a Berthold AG customer in 1992
when Novell Netware did
On Sat, Jun 09, 2007 at 10:16:34PM +0200, [EMAIL PROTECTED] wrote:
>
> >Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in
> >ZFS. Any word on when the fix will be out?
>
> It's a bug in scandir (obviously) and it is filed as such.
>
> Does scandir fail on zfs because of thi
>Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in
>ZFS. Any word on when the fix will be out?
It's a bug in scandir (obviously) and it is filed as such.
Does scandir fail on zfs because of this or does scandir needs to
reallocate and does it use the size as first order est
You have created an unreplicated pool of the form:
pool
raidz
/export/sl1
/export/sl2
/export/sl3
/export/sl4
I believe 'zpool add' will warn you about this, hence needing the '-f'.
You then overwrite the entire cont
dd if=/dev/zero of=sl1 bs=512 count=256000
dd if=/dev/zero of=sl2 bs=512 count=256000
dd if=/dev/zero of=sl3 bs=512 count=256000
dd if=/dev/zero of=sl4 bs=512 count=256000
zpool create -m /export/test1 test1 raidz /export/sl1 /export/sl2 /export/sl3
zpool add -f test1 /export/sl4
dd if=/dev/zero of
On Jun 9, 2007, at 06:14, Richard L. Hamilton wrote:
I wish there was a uniform way whereby applications could
register their ability to achieve or release consistency on demand,
and if registered, could also communicate back that they had
either achieved consistency on-disk, or were unable to d
Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in ZFS.
Any word on when the fix will be out?
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/l
Ed Ravin <[EMAIL PROTECTED]> wrote:
> Why does ZFS report such small directory sizes? For example, take a maildir
> directory with ten entries:
>
> total 2385
> drwx-- 8 17121vmail 10 Jun 8 23:50 .
> drwx--x--x 14 root root 14 May 12 2006 ..
> drwx-- 5 171
Why does ZFS report such small directory sizes? For example, take a maildir
directory with ten entries:
total 2385
drwx-- 8 17121vmail 10 Jun 8 23:50 .
drwx--x--x 14 root root 14 May 12 2006 ..
drwx-- 5 17121vmail 5 May 25 18:16 .Trash
drwx---
Toby Thain <[EMAIL PROTECTED]> wrote:
> > I'll just add, but not for Mac OS X. It was way back in Finder 7
> > days,
> > when they used to ship A/UX. (That was where I cut my unix teeth.)
>
> I was actually thinking more of NEXTSTEP, certainly a generation
> beyond A/UX; and OS X, a generati
I wish there was a uniform way whereby applications could
register their ability to achieve or release consistency on demand,
and if registered, could also communicate back that they had
either achieved consistency on-disk, or were unable to do so. That
would allow backup procedures to automatical
16 matches
Mail list logo