From: Al A. <al_...@ma...> - 2004-02-10 22:47:34
|
Hi Miklos! Sorry for the delayed reply. It's been hectic. >> Yes and no. On the kernel interface level it does, but on the library side it currently doesn't. If you are willing to use the kernel API then you can implement full unix file semantics, including files kept open after unlink, etc... I see. I tried modifying fusexmp and filling in st_ino, but down deeper it ended up ignoring it with a call to next_ino() anyway. I guess that explains it. So I guess the question is, would there be a way to have fuse not generate i-nums for my filesystem, but still work with other fuse filesystems that require this? Perhaps a flag that leaves i-num generation to the userland FS? >> You can also look at FunFS by Michael Grigoriev (http://www.luminal.org/wiki/index.php/FunFS/FunFS), which I think uses the kernel API directly and has a C++ library interface. The author can probably tell you much more. Michael? I checked that link out, and downloaded FunFS. Interesting stuff. Skimming through it, though, I couldn't find where FunFS interfaces with FUSE, which is probably the part that I need to look at. Michael? :) >> Can I ask what is HSM? Sure. Hierarchical Storage Management. Basically, the concept of caching on a networked filesystem level. It seems to me that this would be a breeze to develop using FUSE. Regards, -Al -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm |
From: <Mik...@et...> - 2004-02-12 11:18:14
|
> Yes it would. It seems from what you're saying, though, that this > may not be in line with the goals of fuse. It is, only there was no demand for this up to now. From the start I thought about using either a path based or an inode-reference based interface (this would be very similar to the kernel VFS interface) but the path based won because of simplicity. Now I'm hesitating between an i-num based and an inode-reference based interface. The i-num based is the most generic, and the filesystem can implement any inode lookup algorithm it likes. The inode-reference based is easier to use, because the filesystem doesn't need to implement the i-num -> inode mapping, but this makes the interface more complex and less flexible. What do you think? Miklos -- At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. |
From: Valient G. <vg...@po...> - 2004-02-12 23:34:54
|
I would be interested in avoiding the i-num lookup in fuse because I have to do my own lookup to get extra information for my filesystem. In fuse, you do a i-num -> path lookup and in my filesystem I then do path -> internal data lookup. Do both options you list have the same complexity? Would either of them need a hash table lookup, or is it just a matter of passing an inode struct vs an i-num as the key? thanks, Valient On Fri, 2004-02-13 at 00:16, Miklos Szeredi wrote: > > Yes it would. It seems from what you're saying, though, that this > > may not be in line with the goals of fuse. > > It is, only there was no demand for this up to now. From the start I > thought about using either a path based or an inode-reference based > interface (this would be very similar to the kernel VFS interface) but > the path based won because of simplicity. > > Now I'm hesitating between an i-num based and an inode-reference based > interface. The i-num based is the most generic, and the filesystem > can implement any inode lookup algorithm it likes. The > inode-reference based is easier to use, because the filesystem doesn't > need to implement the i-num -> inode mapping, but this makes the > interface more complex and less flexible. > > What do you think? > > Miklos |
From: Al A. <al_...@ma...> - 2004-02-13 02:34:25
|
>> Now I'm hesitating between an i-num based and an inode-reference based interface. The i-num based is the most generic, and the filesystem can implement any inode lookup algorithm it likes. The inode-reference based is easier to use, because the filesystem doesn't need to implement the i-num -> inode mapping, but this makes the interface more complex and less flexible. Hmm... Would fuse be able to use some or all of the vfs code if you go the inode-reference based route? How ugly would things get if we leave it as an option, and try to do both? -Al -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm |
From: <Mik...@et...> - 2004-02-13 08:23:12
|
> Hmm... > > Would fuse be able to use some or all of the vfs code if you go the > inode-reference based route? No. VFS is too complex, and it's designed for the kernel environment. > How ugly would things get if we leave it as an option, and try to do both? I really only want to create a new interface if there is a clear need for it. So if you don't prefer either of them, that means that I can base my decision on other factors. But if you have a good argument for one or the other, that would help me choose. Miklos -- At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. |
From: <Mik...@et...> - 2004-02-13 08:17:40
|
> I would be interested in avoiding the i-num lookup in fuse because I > have to do my own lookup to get extra information for my filesystem. In > fuse, you do a i-num -> path lookup and in my filesystem I then do path > -> internal data lookup. Ah, OK, that supports the inode struct approach. > Do both options you list have the same complexity? The API would be about the same complexity. The implementation would be more complex in the case of the inode struct, because it would need to contain the i-num -> inode struct mapping. > Would either of them need a hash table lookup, or is it just a > matter of passing an inode struct vs an i-num as the key? I mean, neither of them has to be a key to a lookup. The inode struct would contain the filesystem's private data. And the i-num could also directly reference an object (like in "real" filesystems). But I guess the inode struct approach would be easier to use by most filesystems. Miklos -- At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. |
From: Michael G. <ma...@lu...> - 2004-02-11 01:41:13
|
On Tue, Feb 10, 2004 at 05:47:08PM -0500, Al Al wrote: > I checked that link out, and downloaded FunFS. Interesting stuff. > Skimming through it, though, I couldn't find where FunFS interfaces with > FUSE, which is probably the part that I need to look at. Michael? :) Ehhh... it's kinda all over the place. The main part is wvfuse.{cc,h} - a stream on top of the Fuse file descriptor. wvfusecmd.{cc,h} implements the co-routine that WvFuse spins off for every incoming Fuse request. wvfuseinomgr.{cc,h} is a class on top of 2 on-disk hashes that map paths to inodes and vice versa. PS. The snapshots on the site are actually pretty out of date with respect to the networks/caching layer. If you are looking at that as well, let me know and I'll make some new ones. --=20 Have fun, As the moment elapsed Michael "mag" Grigoriev We walked in slowmotion ma...@lu... Denying the tide http://www.luminal.org We'll find our devotion |
From: <Mik...@et...> - 2004-02-11 13:15:31
|
> I see. I tried modifying fusexmp and filling in st_ino, but down deeper > it ended up ignoring it with a call to next_ino() anyway. I guess that > explains it. Yes, that is what happens. > So I guess the question is, would there be a way to have fuse not generate > i-nums for my filesystem, but still work with other fuse filesystems that > require this? Perhaps a flag that leaves i-num generation to the userland > FS? It could be possible, however there is still a problem: i-num -> path mapping. The current FUSE library can only store a single path for an i-num. Take the following example: - you have two hard links to an inode: l1 and l2 - you open the file via l1 - then you remove l2: libfuse will now remove the path mapping for this node since it can only keep one instance of such a mapping - then you read/write to file: libfuse won't find the file The same happens if you remove a file was previously opened. This is essentially the same problem. This is caused by the "path nature" of the libfuse interface, which can't really be helped by allowing i-num generation to the filesystem. The way to properly solve it is to have a library which has an i-num based interface instead of paths. This makes filesystem implementation a bit harder for most cases, but could provide proper UNIX file semantics and working hard links. Would such an interface suit your needs better? Alternatively (or until I design this new interface) you can use the raw kernel interface like FunFS does or even reuse the code from FunFS. > Sure. Hierarchical Storage Management. Basically, the concept of > caching on a networked filesystem level. Aha, interesting! > It seems to me that this would be a breeze to develop using FUSE. Well, at least you don't have the stability problem of developing a new filesystem under a live system. Miklos -- At the end of this message, my employer might have automatically inserted a stupid disclaimer. This nonsense is out of my control and should simply be ignored. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. |