Re: [9fans] fossil pb: FOUND!
On Sat Jan 14 18:46:44 EST 2012, ara...@mgk.ro wrote: How come? With venti, the address is the SHA-1 hash, with ZFS, you get to chose the hash, but it can still be a hash. because in zfs the hash is not used as an address (lba). True. As I said, neither in Venti. The hash is translated to a lba by the index, a table that can be recreated from the data if it's missing or if it's corrupt. ZFS also uses an index table called DDT. It also has the same properties as Venti's index, it can be created by reading the data. you've confused the internal implementation with the public programming interface. venti IS content-addressed. this is because in the programming interface, one passes addresses data by its hash. venti could internally store its bits in the holes in swiss cheese and it would still be content addressed, not cheese addressed. on the other hand, zfs is not content addressed. this is because, as an iscsi target, zfs will be addressing data by block offset rather than hash. zfs could store its bits in venti, and it still would NOT be content addressed nor would it be venti-addressed. - erik
Re: [9fans] fossil pb: FOUND!
you've confused the internal implementation with the public programming interface. The properties we're discussing here (dedup, fragmentation, performance) are an artifact of the implementation, not of the interface. Fossil+Venti would perform the same if Venti exported its interface only to Fossil, and not to the whole world. In ZFS terms, Fossil is akin to ZPL (ZFS POSIX layer), it implements filesystem semantics over another layer, DMU for ZFS and Venti for Plan9. Please not that ZFS exports more than the filesystem interface, there's also iSCSI (as you noticed), zfs send/recv (remarcably similar to venti/write venti/read, even in their use of standard input/output interface), even bits of the DMU are exported. Hell, even the VFS concrete implementation is exported (though only in kernel mode), else you could not write layered filesystems (not as nice and simple as Plan9 bind(2) but akin to STREAMS filters at filesystem layer). You know I've worked at writing the SMB/CIFS in-kernel filesystem that sits on top of ZFS, right? Well, when you're doing this you have to be careful around this content-addressed thing. I've used the interface you claim it doesn't exist. It's not public? Why is this relevant to the properties of the system? on the other hand, zfs is not content addressed. this is because, as an iscsi target, zfs will be addressing data by block offset rather than hash. zfs could store its bits in venti, and it still would NOT be content addressed nor would it be venti-addressed. That's not fair at all, I could be claiming that venti is not content addressed because you use hierarchical names to address data in a vac archive. Vac is just a layer over venti, like ZPL and iSCSI is a layer over DMU. In this case the properties of the system depend on the properties of the underlying layer, not of the interface, and this layer is content addressed, even by your definition. -- Aram Hăvărneanu
Re: [9fans] fossil pb: FOUND!
sits on top of ZFS, right? Well, when you're doing this you have to be careful around this content-addressed thing. I've used the interface you claim it doesn't exist. It's not public? Why is this relevant to well then, please provide a pointer if this is a public interface. the reason why this is relevant is because we don't call ssds fancy wafl-addressed storage (assuming that's how they do it), because that's now the interface one gets. we don't call raid appliances raid-addressed storage (assuming they're using raid), because that's not the interface presented. - erik
Re: [9fans] du vs. ls: duplication or not?
On Sat, Jan 14, 2012 at 09:20:51AM +, Charles Forsyth wrote: [...] On Linux, I never use ls -R, partly because I'm running p9p's ls, but mainly because the default format of /bin/ls -R is amazingly useless (even worse than I remembered). I wasn't refering to whatever implementation (I don't use ls -R either since the output is simply not parsable). I was simply using -R, since -r is already taken. What I meant was the size of the file is already given via ls(1). So a recursive output that make sense and fit a manipulation via join(1) (to combine a srv/qid) and sort and uniq etc. could do the trick. Since ls(1) gives the size of the file; since du(1) can not really or at least not always in an arbitrary context tells the real occupation of disk size, is not ls(1) enough? -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] du vs. ls: duplication or not?
Since ls(1) gives the size of the file; since du(1) can not really or at least not always in an arbitrary context tells the real occupation of disk size, is not ls(1) enough? plan 9 ls does not have a -R option. - erik
[9fans] Rising intonation
It's not public? read with rising intonation? Charles? I'd never have picked you as as a Kiwi?? But your rising intonation has given you away???
Re: [9fans] Rising intonation
Don't worry cuzz, he's a Bwit. On 16 January 2012 14:07, Winston Kodogo kod...@gmail.com wrote: It's not public? read with rising intonation? Charles? I'd never have picked you as as a Kiwi?? But your rising intonation has given you away??? -- Don't meddle in the mouth -- MVS (0416935147, +1-513-3BRUCEE)
Re: [9fans] du vs. ls: duplication or not?
Hi. What I meant was the size of the file is already given via ls(1). So a recursive output that make sense and fit a manipulation via join(1) (to combine a srv/qid) and sort and uniq etc. could do the trick. Not quite. On Unix (don't remember 'bout Plan 9 but I assume it's the same) files can have holes. All you have to do is lseek pass the end of the file and then write something. Bingo - size (or better, length of the byte stream) no longer has a direct relationship to the number of disk blocks occupied. On Unix systems, du looks in the stat structure at the count of blocks occupied (st_blocks IIRC) and does the computation from that. Similaly, many Unix du implementations will track hard links based on device+inode to only count a file's blocks once. Since ls(1) gives the size of the file; since du(1) can not really or at least not always in an arbitrary context tells the real occupation of disk size, is not ls(1) enough? For the two above reasons, I think not. Again, at least on Unix. :-) (I suppose ls could print device+inode, and sort+join on that to remove duplicates, but the holes problems is still there. Hmmm. I bet ls can print the number of blocks instead of or in addition to the size. So maybe I'm wrong after all. :-) Arnold
