Re: [zfs-discuss] XATTRs, ZAP and the Mac
Maury Markowitz <[EMAIL PROTECTED]> wrote: > So can anyone tell me why xattrs weren't handled in the same way as ACLs? It > smells of inside-the-box-thinking, but I'm no FS expert and there may very > well be a good reason. They are: ACLs (ar least in UFS) are inside a shadow inode that is referenced in the main inode. XATTRs are inside a "shadow" XATTR directors that is referenced in the inode. The difference between Apple does and what Sun does it that Sun's imlementation is not limited and also serves wishes that come from Microsoft. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] XATTRs, ZAP and the Mac
Gregory Shaw <[EMAIL PROTECTED]> wrote: > I don't disagree with the below, however, you can run your mac on UFS > instead of HFS+. Since UFS hasn't been mac-ified, I'm wondering if > the below is actually true for all filesystem types. It seems that UFS has been "mac-ified" on MacOS X. IIRC, you may append "/rsrc" to any file name. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] XATTRs, ZAP and the Mac
Matthew Ahrens <[EMAIL PROTECTED]> wrote: > > I think that's the disconnect. WHY are they "full-fledged files"? > > Because that's what the specification calls for. If they weren't > full-fledged files, they wouldn't be compatable with existing > interfaces. That wouldn't necessarily be a bad thing, just a different > thing. As I mentioned, a new, lighter-weight interface could be > designed in addition to extended attributes. Do you believe this should be done using a new different basic implementation? Note that I would need to know this in order to decide on how to support XATTRs in a OS independent way inside star. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: 'zpool history' proposal
Al Hopper wrote: On Wed, 3 May 2006, Matthew A. Ahrens wrote: # zpool history jen History for 'jen': 2006-04-27T10:38:36 zpool create jen mirror ... I have two suggestions which are just minor nits compared with the rest of this discussion: 1. Why do you print a "T" between the date and the time? I think a space would be more readable. Perhaps its an ISO 8601 formatted date? Yep that's the reason. Or is there another preferred format that is popular to timestamps? 2. When printing the history for a specific pool, I don't think we should print the "History for " line. It seems unnecessary, and that way every line of output will have the same format (better for later machine parsing). I agree. eric ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: XATTRs, ZAP and the Mac
Frank Hofmann <[EMAIL PROTECTED]> wrote: > Yes, Microsoft's FAT does it the same way - the dirent is the inode. > > This creates locking nightmares in its own right - directory scans/updates > may be blocking file access; at the very least, the two race. It might > have advantages in some situations, and simplifies the metadata > implementation - but at least to me, it also causes headaches ... and an > upset stomach every now and then ... With FAT, you are right, but there are other ways to implement hard links. Look at my WOFS from 1990... It uses 'gnodes' that include the filename in one single meta data chunk for a file. Hard links are implemented as inode number related soft links (while symlinks are name related soft links). If ZFS did use my concept, you don't have the problems you have with FAT. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS RAM requirements?
Roch Bourbonnais - Performance Engineering schrieb: A already noted, this needs not be different from other FS but is still an interesting question. I'll touch 3 aspects here - reported freemem - syscall writes to mmap pages - application write throttling Reported freemem will be lower when running with ZFS than say UFS. The UFS page cache is considered as freemem. ZFS will return it's 'cache' only when memory is needed. So you will operate with lower freemem but won't actually suffer from this. The RAM usage should be made more transparent to the administrator. Just today, after installing snv_37 on another machine, I couldn't disable swap because zfs has grabbed all free memory it could get and didn't release it (even after a "zfs export"): # swap -l swapfile dev swaplo blocks free /dev/md/dsk/d2 85,4 8 4193272 4193272 # swap -s total: 275372k bytes allocated + 93876k reserved = 369248k used, 1899492k available # swap -d /dev/md/dsk/d2 /dev/md/dsk/d2: Not enough space # kstat | grep pp_kernel pp_kernel 872514 # prtconf | head -2 System Configuration: Sun Microsystems i86pc Memory size: 4095 Megabytes # zpool export pool # zpool list no pools available # swap -d /dev/md/dsk/d2 This was shortly after installation with not much running on the machine. To speed up 'mirroring' of swap I usually do the following (but couldn't in this case): swap -d /dev/md/dsk/d2 metaclear d2 metainit d2 -m d21 d22 0 swap -a /dev/md/dsk/d2 Daniel ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Shrinking directories?
I was doing some tests with creating and removing subdirectories and watching the time that takes. The directory retains the size and performance issues after the files are removed. /rootz/test> ls -la . total 42372 drwxr-xr-x 2 add root 2 May 7 23:20 . drwxr-xr-x 3 root sys3 May 7 00:34 .. /rootz/test> time du -ak . 21184 . real0m28.497s user0m0.002s sys 0m1.174s /rootz/test> zfs list NAME USED AVAIL REFER MOUNTPOINT rootz 21.9M 978M 20.7M /rootz Is there any way to ask ZFS to reclaim or shrink the allocation on the directory without actually deleting the directory like I would have to do under UFS? -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
