Slides:

Slides available here

Questions:

Michael DiBernardo:


The abstraction of the virtual disk is used here to make multiple physical disks appear as one disk to the client. However, do you think this abstraction could be useful in other contexts? Notice that the abstraction is devoid of assumptions of how the underlying storage devices are designed (no dependence on cylinders, rotation, etc.)

Frangipani appears to require a great deal of trust between clients and servers. How does this limit its utility in practice?

Sam Davis:


Can files migrate from one disk to another so that they will be closer to the machine that is using them (like objects in a distributed object system)? This might especially make sense if user programs are running on the same machines as the Petal servers.

Suppose that a user wants their machine to become a Petal server. Can their existing file system be made accessible via Frangipani, or would they have to copy their data into Frangipani and wipe (part of) their disk?

Aiman Erbad:


What security problems does the client/server of frangipani exposes? If we use the separate client and server configuration they propose and add the an access protocol (DCE|DFS)? How would the performance be affected?

If the lease expires in the case of a network partition, the lock will be given to another server. What do they propose to solve it? What are the advantages and disadvantages?

Wilson Fung:


Thoughout the paper, the author keep emphasising that Frangipani is highly reliable, but provides not data (eg. mean time failure in a field test) for this claim. Is this norm in this field? Or the data is presented in the paper for Petal?

Does avoiding cache-to-cache transfer give any explicit advantage other than simplicity? In doing so, what is sacrified here? Does it matter at all?

Ali Bakhoda:


How much complex would be a real-world implementation of this system when we consider the level of trust required among the servers and clients as well as the required LAN privacy? Separating inodes and data blocks completely into different regions on petal might result in the inodes and data blocks to be on different servers within petal. How much does this issue affect the cost of file lookups? The focus of fragipani is on improving file sharing performance. Is it still a good option when number of shared files is very low?

Haoran Song:


The paper presents an idea of separating inodes and data block completely into different regions on petal. But I think the cost of a looking up a file might be more expensive because the inodes and data blocks may locate on different servers within petal. What do you think?

What happens if two or more server try to write to the same file? It seems this could cause performance issues because system call could cause a lock revocation request with every write and this can result in the lock holder to flush the dirty data to the Petal.

Frangipani codes are implemented in the kernels, which means it is hard to port this file system to different operating systems. How to improve the portability?

Nguyet Nguyen:


What are the drawbacks of the Frangipani file system?. Frangipani works well for a cluster of workstations that are trusted. Do you think it is a drawback in Frangipani security?. If we can modify the design of the file system to make it more secure, what do you suggest?. Frangipani provides a consistent view of the same set of files to all clients. It means that the concurrency control is important too, do you think the locking system of the file system works efficiently?. It seems like it is too costly.

Kevin Loken:


Frangipani uses taditional block allocations fo ruser data. Would it benefit from log structured suer data to gain further improvements on throughput?

Does the 64 KB chunk allocation in the virtual disk affect disk wastage, or is it resolved at sync?

Seonah Lee:


In Section 2.3, the authors discuss three weakness of Frangipani. Have the following papers solved the issues? Specially, the second weakness that Frangipani can not use location information could be problematic when several servers are located in far distance and a user wants to address the location of the server to speed up the access to the files in the server.

Where logging generally makes a system slow, Frangipani uses the logging function in order to improve its performance (Section 4). Would you clarify the mechanism enabling the performance improvement?

The paper describes a scalable distributed file system, while scalability is important to the company providing web service using a lot of servers (ex. Google). How are the two kinds of scalability different or related to?

Billy Cheung:


Regarding the recovery of Frangipani servers, the paper mentions that it requires a clerk of another Frangipani machine to perform system recovery and process all the server's logs, and that recovery server is itself 'protected' by a lease on the lock it has of the failed server so that if anything happened to it, there will be a recovery recovery server. Now what happens if the lock server dies at the same time?

The authors were 'optimistic' about its ability to scale given its performance with 7 petal nodes and 6 Frangipani nodes, but are there any follow-up papers on its limitations?

Mehmet Alparslan:


Write ahead logging is used for recovering only metadata failures, and does not deal with user data. Instead backup mechanism (i.e. snapshot) in the petal is used against failures. I was wondering if that`s a reasonable choice to make (not logging user data)? What are the current trends?

Frangipani file system needs a secure, closed network system to operate on for security reasons. One might argue that machines outside of the system can be used as clients to overcome these security issues, however even with that configuration the system loses some of ts properties.(coherence)On the other hand one of the main goals of Frangipani is scalability, flexibility to grow. Even though working in a closed system and scalability are not exact opposites I still find these two concepts acting against each other. What do you think?

Gary Huang:


Two-layer structure makes Frangipani File system distributed, scalable, and fault-tolerant. Is there any overhead to create two-layer structure?

Why isnt the Frangipani File system widely used today?

Erica Zhang:


I think the focus of Fragipani seems to be on improving performance for file sharing. I wonder if this system could still work so great when sharing is very low. What is your idea ?

Normal OSes could also support storage systems. Could you analyze the advantages and disadvantages of Fragipani compared with the application of those OSes ?

Mayukh Saubhasik:


What is the degree of replication in petal ?

Can Frangipani / Petal scale beyond a LAN environment onto a large scale distributed environment ? (The system seems to abstract out all details about the locality of storage)

Lloyd Markle:


In section 4 they describe file recovery will offer the same guarentees as a Unix file system but is this true? Is it safe to make this kind of assumption in a distributed world?

One of their goals was to make this file system easy to implement but that was mainly accomplished because of Petal but I don't think it's clearly stated what Petal does and what Frangipani does. Where do we draw the line between the two?

Henry Wong:


Would it be possible/easy to implement file locking on LBFS (rather than last-write wins)? Would there necessarily be a major performance degredation? Given they are targetting wide-area links: How sensitive is performance on Packet loss? (e.g. 10% loss, or loss when transmitting bursts). CIFS (at least on Windows 2000) seems to do rather poorly.

Jean-Sebastien Legare:


It seems like Petal does most of the work. Petal handles the replication, the "virtualization" of the disks, it stores the logs, provides backups (through snapshots), and handles recovery in case of crashes. One important aspect that was neither handled by Petal nor Frangipani is security. What is it that makes is so hard to provide adequate security mechanisms ? Do we not need security ?

I believe the idea of having a file system composed of multiple layers (e.g. distribution/replication layer and lock management layer) allows for both component reusability (e.g. many different file systems could be atop Petal) and simpler implementations (The paper claims Frangipani took 2 months to write). Do you think performance could have been higher if Frangipani had been built "inside" Petal?

Ivan Sham:


How does a network file system differ from something like a centralized file server in terms of performance and availablity?

Will it be easier to implement security and access control in a file server?

Mirna Limic :


Why do you think the authors inmplemented Frangipani to run in the kernel rather than as an application? Would Frangipani be able to be secure if running as an application?

When a server fails it can be restarted with an empty metadata log. Would you say that this could be a problem?

Karthik Chandrasekar :


In implementing the Frangipani server in a Distributed environment, security becomes an issue and the use of such a system is restricted to a secure sub-network. So do you think Frangipani is securely scalable? (Even if we neglect the effect of network congestions)

When two servers simultaneously write to the same file, isn't the performance affected because of lock revocation requests and subsequent overhead involved?

Discussion Recap

The discussion for this paper started with a question on how Frangipani would scale to a WAN. The answer arrived at was that Frangipani was designed as a clustering file system and hence the issue of scaling to a WAN level was not probably handled by the designers. Next the portability issues of Frangipani due to its implementation as a kernel module was discussed and the choice of such a design was made clear. Then the general lack of security in Frangipani was discussed and the question of whether a high level of security was necessary for a clustered system was raised. The discussion then moved on to the performance of Frangipani, firstly how logging increases the performance through asynchronous file-system meta data updates. Then the issue of multiple concurrent writes to the same file in Frangipani and the paper's argument that engineering workloads have rare file access concurrency was discussed. The performance degradation that might happen by potential separation of inodes and their associated data blocks on different disks on the virtual disk drive came up next as part of the discussion on performance. A question that came up was the application scenarios for such a distributed file system other than engineering workloads. The discussion then moved on to the pros and cons of the two-layered petal/frangipani approach with the conclusion that there was a trade off between simplicity by abstraction and performance/flexibility when using the two-layered approach. The discussion ended with a comparison between Frangipani and a centralized file server with regard to performance, availability and security issues.