This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "". The branch, master has been updated via 55e5316dbd6ecb26a1507b5d03f52c113278e045 (commit) from aabe2c73d336fc95e2a56956b19f4e4ee173a793 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 55e5316dbd6ecb26a1507b5d03f52c113278e045 Author: cengiz <[email protected]> Date: Sun Apr 7 15:47:12 2013 -0400 Done with most of the changes recommended in the meeting * Still need to modify related work and intro ----------------------------------------------------------------------- Summary of changes: papers/asg-osd/paper.bib | 10 +- papers/asg-osd/paper.tex | 268 ++++++++++++++++++++++++--------------------- papers/asg-osd/usenix.sty | 95 ---------------- 3 files changed, 148 insertions(+), 225 deletions(-) delete mode 100644 papers/asg-osd/usenix.sty Diff of changes: diff --git a/papers/asg-osd/paper.bib b/papers/asg-osd/paper.bib index faac40c..71f46b5 100644 --- a/papers/asg-osd/paper.bib +++ b/papers/asg-osd/paper.bib @@ -584,11 +584,6 @@ title = {{Design of an Intelligent Object-based Storage device}}, address = {Berkeley, CA, USA}, } -@misc{librados-doc, - title = {{Librados API documentation}}, - url = {http://ceph.com/docs/master/api/librados/} -} - @inproceedings{weil:pdsw07, address = {Reno, NV}, author = {Weil, Sage A. and Leung, Andrew and Brandt, Scott A. and Maltzahn, Carlos}, @@ -601,3 +596,8 @@ title = {{Design of an Intelligent Object-based Storage device}}, title = {{RADOS: A Fast, Scalable, and Reliable Storage Service for Petabyte-scale Storage Clusters}}, year = {2007} } + +@misc{librados-doc, + title = {{Librados API documentation}}, + url = {http://ceph.com/docs/master/api/librados/} +} diff --git a/papers/asg-osd/paper.tex b/papers/asg-osd/paper.tex index 9d6baa3..2882929 100644 --- a/papers/asg-osd/paper.tex +++ b/papers/asg-osd/paper.tex @@ -63,8 +63,8 @@ % should be used if it is desired that the figures are to be displayed in % draft mode. % -\documentclass[10pt, conference, compsocconf]{IEEEtran} -% Add the compsocconf option for Computer Society conferences. +\documentclass[conference]{IEEEtran} +% Add the compsoc option for Computer Society conferences. % % If IEEEtran.cls has not been installed into the LaTeX system files, % manually specify the path to it like: @@ -356,21 +356,24 @@ % author names and affiliations -% use a multiple column layout for up to two different +% use a multiple column layout for up to three different % affiliations - -%\author{\IEEEauthorblockN{Authors Name/s per 1st Affiliation (Author)} -%\IEEEauthorblockA{line 1 (of Affiliation): dept. name of organization\\ -%line 2: name of organization, acronyms acceptable\\ -%line 3: City, Country\\ -%line 4: Email: [email protected]} +%\author{\IEEEauthorblockN{Michael Shell} +%\IEEEauthorblockA{School of Electrical and\\Computer Engineering\\ +%Georgia Institute of Technology\\ +%Atlanta, Georgia 30332--0250\\ +%Email: http://www.michaelshell.org/contact.html} +%\and +%\IEEEauthorblockN{Homer Simpson} +%\IEEEauthorblockA{Twentieth Century Fox\\ +%Springfield, USA\\ +%Email: [email protected]} %\and -%\IEEEauthorblockN{Authors Name/s per 2nd Affiliation (Author)} -%\IEEEauthorblockA{line 1 (of Affiliation): dept. name of organization\\ -%line 2: name of organization, acronyms acceptable\\ -%line 3: City, Country\\ -%line 4: Email: [email protected]} -%} +%\IEEEauthorblockN{James Kirk\\ and Montgomery Scott} +%\IEEEauthorblockA{Starfleet Academy\\ +%San Francisco, California 96678-2391\\ +%Telephone: (800) 555--1212\\ +%Fax: (888) 555--1212}} % conference papers do not typically use \thanks and this command % is locked out in conference mode. If really needed, such as for @@ -408,6 +411,7 @@ \begin{abstract} +%\boldmath Distributed object-based storage models are an increasingly popular alternative to traditional block-based or file-based storage abstractions in large-scale storage systems. Object-based storage models store and access data @@ -416,21 +420,26 @@ easier data sharing, locality and better security compared to traditional storag Although many large-scale storage systems share common goals of performance, scalability and fault tolerance, their underlying storage models are typically tailored to specific classes of applications through incremental evolution of previous standards. -In this paper, we propose a new distributed object-based storage API -that seeks to combine data access features (i.e. concurrent reads\&writes, versioning, +In this paper, we propose a new distributed object-based storage model, ASG, +that seeks to combine data access features (i.e. concurrent reads and writes, versioning, conditional operations, failure handling) into a unified API that is suitable for use as a base model in a wide range of contexts, including file systems, cloud storage, databases, HPC systems and big data. We identify the common requirements of these data models, identify key -features of previous object-based storage interfaces, and explore how they can be unified effectively +features of previous object-based storage models and explore how they can be unified effectively without sacrificing usability. We validate the effectiveness of our approach with case studies -that evaluate how the storage API we are proposing can be used to construct a namespace and a -column-store database. +that evaluate how ASG storage model can be used to construct a namespace and a +column-store database and to support concurrent write accesses. \end{abstract} +% IEEEtran.cls defaults to using nonbold math in the Abstract. +% This preserves the distinction between vectors and scalars. However, +% if the conference you are submitting to favors bold math in the abstract, +% then you can use LaTeX's standard command \boldmath at the very start +% of the abstract to achieve this. Many IEEE journals/conferences frown on +% math in the abstract anyway. + +% no keywords -%\begin{IEEEkeywords} -%component; formatting; style; styling; -%\end{IEEEkeywords} % For peer review papers, you can put extra information on the cover @@ -453,41 +462,42 @@ Modern applications demand high-performance, security and portability from the s computers and this requires the storage units to redefine the abstraction to store and manage data. In order to meet these demands, a new storage model called \textit{object-based storage} has been developed ~\cite{1222722, osd-3}. Storage devices that store and access data according to the object-based storage -model are called as \textit{object-based storage devices}. Storage system developers prefer to build -software implementations of object-based storage model on block-based devices; since there is no hardware -implementation of an object-based storage device yet. +model are called as \textit{object-based storage devices}. %\textit{properties of the object-based storage model} An \textit{object} is an ordered logical collection of bytes with a numerical identifier. Objects consist -of data, user settable attributes and device managed metadata including security policies that protect data +of data, attributes and device managed metadata including security policies that protect data ~\cite{1222722, Welch08scalableperformance}. They have variable sizes and they can be used to store any -kind of data in the storage system. Having data organized as objects makes it possible for a -disk to do data management operations on behalf of a user~\cite{5944457} and offloads the storage -management task from the host operating system to the object-based storage. User-settable attributes can -be further enriched to set performance goals, manage replicas or handle concurrency in object-based -storage model to enable self-management capabilities and they give the user an effective control of data -on the disk~\cite{gibson:storage, 5944457}. Object-based storage is also suitable for realizing -\textit{active storage}~\cite{5944457,Acharya:1998:ADP:291006.291026, riedel:thesis}; because objects -provide more features to encapsulate the computations compared to traditional blocks. +kind of data in the storage system. Having data organized as objects enables offloading storage +management tasks; such as block remapping and space management from the host operating system to the +object-based storage. Object attributes can be further enriched to set performance goals, manage replicas +or handle concurrency in object-based storage model to enable self-management capabilities and they give +the user an effective control of data~\cite{gibson:storage, 5944457}. Object-based storage is +also suitable for realizing \textit{active storage}~\cite{5944457,Acharya:1998:ADP:291006.291026, +riedel:thesis}; because objects provide more features to encapsulate the computations compared to +traditional blocks. Although several object-based storage models have already been implemented and used as the basis for the popular storage and file systems~\cite{Weil06ceph:a, Beaver:2010:FNH:1924943.1924947, lustre-web}, these object-based storage models are often tailored to a particular use case or data model. %\textit{Requirements of common data models (file systems, cloud storage, databases and big data)} On the other hand, common data applications; such as file systems, cloud storage, databases and big data -require the underlying storage models to support various features; such as concurrency, reliability, +need the underlying storage models to meet specific requirements; such as concurrency, reliability, scalability and flexible data structures. %Although object-based storage model has been investigated in many research studies and several %optimizations have been introduced for this model, we believe that the object-based storage model %primitives need to be revisited. -In this work we propose a new object-based storage model, known as the ASG interface, that seeks to unify +In this work we propose a new object-based storage model, known as ASG, that seeks to unify the features necessary to support the data models outlined above without compromising usability or -limiting implementation flexibility. ASG interface intends to bring versioning, conditional operation, -fork\&record structure and unified data\&attribute features together. The rest of the paper is organized -as follows; Section 2 talks about related work in object-based storage systems. Section 3 describes the -ASG architecture in details. Section 4 compares the ASG model with existing T10 model and identifies the -advantages\&disadvantages of each model. We give sample usage scenarios of ASG model in Section 5 followed -by the conclusion and possible directions for future development of ASG in Section 6. +limiting implementation flexibility. Object-based storage model was developed to be implemented in +hardware originally~\cite{osd-3}; however storage system developers has preferred to implement object-based +storage as a software layer~\cite{1306916, Devulapalli07integratingparallel, librados-doc, lustre-web} and +ASG storage model follows this design decision too. ASG storage model brings versioning, conditional +operation, fork and record structure and unified data and attribute features together. The +rest of the paper is organized as follows; Section~\ref{primitives} describes the ASG architecture in +details and presents example use cases. Section~\ref{relatedwork} talks about related work in object-based +storage systems. We finish with conclusion and possible directions for future development of ASG in +Section~\ref{conclusion}. %\textit{Describe the sections in the remainder of the paper} %We believe an object-based storage system can offer a lot more sophisticated functionalities by @@ -495,66 +505,7 @@ by the conclusion and possible directions for future development of ASG in Secti %system model, ASG, that unifies the conditional operation and versioning features previously explored in %related studies described in the previous paragraph. -\section{Related Work} -Network-Attached Secure Disk (NASD)~\cite{gibson:storage} is the primary study on -object-based storage and it led to specifications of standards~\cite{osd-3} for object-based -storage. -%It is based on the idea of integrating the disk management functions into the storage -%device and it offers a variable-length object-storage interface. -NASD introduces variable-length objects with attributes, rather than fixed-length traditional blocks, to -enable self-management and to obviate the need to know about the host operating system. Moving data -management to the storage disks increases the networking, security and space management capabilities. - -There have been numerous studies in literature with similar scope to our work. -OSD+~\cite{springerlink:10.1007/s10766-012-0207-8,10.1109/SBAC-PAD.2011.12} presents a model very similar -to the one specified by the OSD standard~\cite{osd-3} except for the addition of dedicated directory -objects. The directory objects in OSD+ store file names and attributes and support metadata related -operations. -%Each OSD+ stores a single directory object. -%In order to guarantee correctness and atomicity, OSD+ relies on the back-end file system (Ext3, Ext4) and -%three-phase commit protocol~\cite{Skeen:1983:FMC:1313337.1313750}. -Panasas File System~\cite{Welch08scalableperformance} is built on object-based storage devices. -%Panasas File System clients have direct access to the objects which are a combination of data and -%attributes. -OSD wire protocol of Panasas uses the operations from the OSD standard~\cite{osd-3} to enable byte-oriented -access to data, to manipulate attributes and to create or delete objects. -%Panasas clients use iSCSI/OSD protocol to access the object-based storage devices. -Lustre~\cite{lustre-web} is a distributed file system based on object-based storage. Object Storage -Server (OSS) in Lustre is responsible for providing access to file data stored in objects on Object -Storage Targets (OSTs). -%Lustre has two types of servers; Metadata Server (MDS) and Object Storage Server (OSS). Actual metadata is -%stored on Metadata Targets (MDTs) and file data is stored on Object Storage Targets (OSTs) as objects. MDS -%is responsible for handling metadata requests and making the metadata stored in MDTs available to the -%clients; whereas OSS is responsible for filesystem I/O and for providing access to file data stored on -%OSTs. -\textit{Ursa Minor} is a parallel file system that supports versioned writes. It keeps the existing -object-storage interface~\cite{osd-3} mostly intact except for introducing \textit{slices} which are -fragments of object data and it uses timestamps to distinguish different versions of data. -Datamods~\cite{watkinsdatamods} is a framework that exploits existing large-scale storage system services -to support complex data models and interfaces. -%Traditionally middleware is tailored to support specific data models; however many services provided by -%middleware already exist in distributed storage systems. -Datamods avoids duplicating services already provided in distributes storage systems in middleware and -improves scalability since it is not limited to single dimension at the file level. -RADOS~\cite{librados-doc, weil:pdsw07} is an object storage service forming the foundation of -Ceph~\cite{Weil06ceph:a}. It provides the clients a single logical object store and offloads object -replication, failure detection and data management tasks to the underlying object store daemons. -Ohio Supercomputing Center looked at mapping Parallel Virtual File System~\cite{pvfs-web} on top of an -existing object-based storage emulation~\cite{1306916, Devulapalli07integratingparallel}. This mapping -moved the functionality of the common components of a traditional storage system; such as I/O, directory -or metadata servers to OSDs and improved the performance of the overall system due to the capabilities of -the object-based storage devices ~\cite{OSDCluster08, OSDPDSI08, 10.1109/SNAPI.2008.14}. - -A number of studies form the technical basis of our work. Transactional Object Storage Device (TOSD) -~\cite{carns2010object} shows that object-based storage is a common component of many parallel file -systems and it introduces three optimizations to the object-based storage model in order to serve highly -concurrent workloads better; atomicity, versioning and commutativity. Goodell et al.~\cite{goodell-pdsw12} -extended the POSIX API by organizing the storage around data objects in order to map complex data -structures to these data objects and have direct access between the data objects and applications. Carns -et al.~\cite{carns-pdsw12} investigated conditional update operations as an alternative to distributed -pessimistic locking operations in object-based storage systems. - -\section{Implementation Strategies} +\section{Proposed Model} \label{primitives} In this section we describe the ASG storage model, its fundamental building blocks and basic primitives. @@ -671,27 +622,12 @@ be retrieved. The retrieved information consists of the identifier of the first container/object/fork/record existing in the given entity, number of containers/objects/forks/records, total number of records and the version numbers of these records. -\section{Comparison with Existing Models} -Wisconson Storage System (WiSS) is a flexible storage system developed for the UNIX -environment~\cite{DBLP:journals/spe/ChouDKK85}. It supports unconventional types of data and it consists of -four distinct layers; \textit{level 0}, \textit{level 1}, -\textit{level 2} and \textit{level 3}. The basic structure units of WiSS are \textit{pages} at -\textit{level 0}. \textit{Level 0} performs I/O operations on pages. \textit{Level 1} is responsible for -maintaining a buffer pool of pages to make the access to the important pages faster. \textit{Level 2} of -WiSS carries some similarities to the ASG storage model. This level consists of \textit{records}, each of -which stored in an underlying page. A record consists of record type, record length and actual data. Record -length and actual data also exist in ASG records. Similar to the ASG storage model, each record is known by -a numerical identifier. Unlike ASG, records in WiSS have unique identifiers; whereas records in different -enclosing objects or forks etc. in ASG can have the same identifier. WiSS supports B-trees to index records -and long data items (a collection of pages) to store unlimited size of data; however in ASG there are no -such mechanisms yet. WiSS uses locking at the file granularity; whereas ASG supports versioning to provide -concurrency. \textit{Level 3} of WiSS has primitives to create or delete files using low-level primitives -which is similar to the Namespace Implementation we will discuss in Section~\ref{namespace}. - -\section{Sample Use Case: Namespace Implementation} +\subsection{Example Use Cases} \label{namespace} -In this section we show how versioning and conditional operations can be used in ASG storage model; by implementing namespace operations as an example. +In this section we show how ASG storage model can be used as a basis to construct a namespace and a column +store and to support concurrent write accesses. +\subsubsection{Namespace Implementation} A namespace can be defined as an abstract collection of unique keys. A key can be in a string or integer format and it may appear in more than one namespaces with or without having the same meaning; but it needs to be unique in each of these namespaces. The uniqueness property of @@ -736,12 +672,34 @@ namespace, update returns error. It calls underlying \textit{read} and \textit{w \end{itemize} +\subsubsection{Column Store} +Column Store use case will go here. + +\subsubsection{Concurrent Write Access} +Concurrent Write Access use case will go here. + +%\section{Comparison with Existing Models} +%Wisconson Storage System (WiSS) is a flexible storage system developed for the UNIX +%environment~\cite{DBLP:journals/spe/ChouDKK85}. It supports unconventional types of data and it consists of +%four distinct layers; \textit{level 0}, \textit{level 1}, +%\textit{level 2} and \textit{level 3}. The basic structure units of WiSS are \textit{pages} at +%\textit{level 0}. \textit{Level 0} performs I/O operations on pages. \textit{Level 1} is responsible for +%maintaining a buffer pool of pages to make the access to the important pages faster. \textit{Level 2} of +%WiSS carries some similarities to the ASG storage model. This level consists of \textit{records}, each of +%which stored in an underlying page. A record consists of record type, record length and actual data. Record +%length and actual data also exist in ASG records. Similar to the ASG storage model, each record is known by +%a numerical identifier. Unlike ASG, records in WiSS have unique identifiers; whereas records in different +%enclosing objects or forks etc. in ASG can have the same identifier. WiSS supports B-trees to index records +%and long data items (a collection of pages) to store unlimited size of data; however in ASG there are no +%such mechanisms yet. WiSS uses locking at the file granularity; whereas ASG supports versioning to provide +%concurrency. \textit{Level 3} of WiSS has primitives to create or delete files using low-level primitives +%which is similar to the Namespace Implementation we will discuss in Section~\ref{namespace}. + % no \IEEEPARstart %This demo file is intended to serve as a ``starter file'' %for IEEE conference papers produced under \LaTeX\ using %IEEEtran.cls version 1.7 and later. -%All manuscripts must be in English. These guidelines include complete descriptions of the fonts, spacing, and related information for producing your proceedings manuscripts. Please follow them and if you have any questions, direct them to the production editor in charge of your proceedings at Conference Publishing Services (CPS): Phone +1 (714) 821-8380 or Fax +1 (714) 761-1784. % You must have at least 2 lines in the paragraph with the drop letter % (should never be an issue) @@ -838,9 +796,68 @@ namespace, update returns error. It calls underlying \textit{read} and \textit{w % footnotes above bottom floats. This can be corrected via the \fnbelowfloat % command of the stfloats package. +\section{Related Work} +\label{relatedwork} +Network-Attached Secure Disk (NASD)~\cite{gibson:storage} is the primary study on +object-based storage and it led to specifications of standards~\cite{osd-3} for object-based +storage. +%It is based on the idea of integrating the disk management functions into the storage +%device and it offers a variable-length object-storage interface. +NASD introduces variable-length objects with attributes, rather than fixed-length traditional blocks, to +enable self-management and to obviate the need to know about the host operating system. Moving data +management to the storage disks increases the networking, security and space management capabilities. +There have been numerous studies in literature with similar scope to our work. +OSD+~\cite{springerlink:10.1007/s10766-012-0207-8,10.1109/SBAC-PAD.2011.12} presents a model very similar +to the one specified by the OSD standard~\cite{osd-3} except for the addition of dedicated directory +objects. The directory objects in OSD+ store file names and attributes and support metadata related +operations. +%Each OSD+ stores a single directory object. +%In order to guarantee correctness and atomicity, OSD+ relies on the back-end file system (Ext3, Ext4) and +%three-phase commit protocol~\cite{Skeen:1983:FMC:1313337.1313750}. +Panasas File System~\cite{Welch08scalableperformance} is built on object-based storage devices. +%Panasas File System clients have direct access to the objects which are a combination of data and +%attributes. +OSD wire protocol of Panasas uses the operations from the OSD standard~\cite{osd-3} to enable byte-oriented +access to data, to manipulate attributes and to create or delete objects. +%Panasas clients use iSCSI/OSD protocol to access the object-based storage devices. +Lustre~\cite{lustre-web} is a distributed file system based on object-based storage. Object Storage +Server (OSS) in Lustre is responsible for providing access to file data stored in objects on Object +Storage Targets (OSTs). +%Lustre has two types of servers; Metadata Server (MDS) and Object Storage Server (OSS). Actual metadata is +%stored on Metadata Targets (MDTs) and file data is stored on Object Storage Targets (OSTs) as objects. MDS +%is responsible for handling metadata requests and making the metadata stored in MDTs available to the +%clients; whereas OSS is responsible for filesystem I/O and for providing access to file data stored on +%OSTs. +\textit{Ursa Minor} is a parallel file system that supports versioned writes. It keeps the existing +object-storage interface~\cite{osd-3} mostly intact except for introducing \textit{slices} which are +fragments of object data and it uses timestamps to distinguish different versions of data. +Datamods~\cite{watkinsdatamods} is a framework that exploits existing large-scale storage system services +to support complex data models and interfaces. +%Traditionally middleware is tailored to support specific data models; however many services provided by +%middleware already exist in distributed storage systems. +Datamods avoids duplicating services already provided in distributes storage systems in middleware and +improves scalability since it is not limited to single dimension at the file level. +RADOS~\cite{librados-doc, weil:pdsw07} is an object storage service forming the foundation of +Ceph~\cite{Weil06ceph:a}. It provides the clients a single logical object store and offloads object +replication, failure detection and data management tasks to the underlying object store daemons. +Ohio Supercomputing Center looked at mapping Parallel Virtual File System~\cite{pvfs-web} on top of an +existing object-based storage emulation~\cite{1306916, Devulapalli07integratingparallel}. This mapping +moved the functionality of the common components of a traditional storage system; such as I/O, directory +or metadata servers to OSDs and improved the performance of the overall system due to the capabilities of +the object-based storage devices ~\cite{OSDCluster08, OSDPDSI08, 10.1109/SNAPI.2008.14}. + +A number of studies form the technical basis of our work. Transactional Object Storage Device (TOSD) +~\cite{carns2010object} shows that object-based storage is a common component of many parallel file +systems and it introduces three optimizations to the object-based storage model in order to serve highly +concurrent workloads better; atomicity, versioning and commutativity. Goodell et al.~\cite{goodell-pdsw12} +extended the POSIX API by organizing the storage around data objects in order to map complex data +structures to these data objects and have direct access between the data objects and applications. Carns +et al.~\cite{carns-pdsw12} investigated conditional update operations as an alternative to distributed +pessimistic locking operations in object-based storage systems. \section{Conclusions and Future Work} +\label{conclusion} ASG storage model is good and can be further improved to support snapshotting, dynamic namespaces etc. % conference papers do not normally have an appendix @@ -851,7 +868,8 @@ ASG storage model is good and can be further improved to support snapshotting, d %The authors would like to thank... -%more thanks here + + % trigger a \newpage just before the given reference @@ -884,7 +902,7 @@ ASG storage model is good and can be further improved to support snapshotting, d %\end{thebibliography} -\bibliographystyle{plain} +\bibliographystyle{IEEEtran} \bibliography{pario,REFERENCES,paper} % that's all folks diff --git a/papers/asg-osd/usenix.sty b/papers/asg-osd/usenix.sty deleted file mode 100644 index debc97b..0000000 --- a/papers/asg-osd/usenix.sty +++ /dev/null @@ -1,95 +0,0 @@ -% usenix.sty - to be used with latex2e for USENIX. -% To use this style file, look at the template usenix_template.tex -% -% $Id: usenix.sty,v 1.2 2005/02/16 22:30:47 maniatis Exp $ -% -% The following definitions are modifications of standard article.sty -% definitions, arranged to do a better job of matching the USENIX -% guidelines. -% It will automatically select two-column mode and the Times-Roman -% font. - -% -% USENIX papers are two-column. -% Times-Roman font is nice if you can get it (requires NFSS, -% which is in latex2e. - -\if@twocolumn\else\input twocolumn.sty\fi -\usepackage{mathptmx} % times roman, including math (where possible) - -% -% USENIX wants margins of: 1" sides, 1" bottom, and 1" top. -% 0.25" gutter between columns. -% Gives active areas of 6.5" x 9" -% -\setlength{\textheight}{9.0in} -\setlength{\columnsep}{0.25in} -\setlength{\textwidth}{6.50in} - -\setlength{\topmargin}{0.0in} - -\setlength{\headheight}{0.0in} - -\setlength{\headsep}{0.0in} - -% Usenix wants no page numbers for camera-ready papers, so that they can -% number them themselves. But submitted papers should have page numbers -% for the reviewers' convenience. -% -% -% \pagestyle{empty} - -% -% Usenix titles are in 14-point bold type, with no date, and with no -% change in the empty page headers. The whole author section is 12 point -% italic--- you must use {\rm } around the actual author names to get -% them in roman. -% -\def\maketitle{\par - \begingroup - \renewcommand\thefootnote{\fnsymbol{footnote}}% - \def\@makefnmark{\hbox to\z@{$\m@th^{\@thefnmark}$\hss}}% - \long\def\@makefntext##1{\parindent 1em\noindent - \hbox to1.8em{\hss$\m@th^{\@thefnmark}$}##1}% - \if@twocolumn - \twocolumn[\@maketitle]% - \else \newpage - \global\@topnum\z@ - \@maketitle \fi\@thanks - \endgroup - \setcounter{footnote}{0}% - \let\maketitle\relax - \let\@maketitle\relax - \gdef\@thanks{}\gdef\@author{}\gdef\@title{}\let\thanks\relax} - -\def\@maketitle{\newpage - \vbox to 2.5in{ - \vspace*{\fill} - \vskip 2em - \begin{center}% - {\Large\bf \@title \par}% - \vskip 0.375in minus 0.300in - {\large\it - \lineskip .5em - \begin{tabular}[t]{c}\@author - \end{tabular}\par}% - \end{center}% - \par - \vspace*{\fill} -% \vskip 1.5em - } -} - -% -% The abstract is preceded by a 12-pt bold centered heading -\def\abstract{\begin{center}% -{\large\bf \abstractname\vspace{-.5em}\vspace{\z@}}% -\end{center}} -\def\endabstract{} - -% -% Main section titles are 12-pt bold. Others can be same or smaller. -% -\def\section{\@startsection {section}{1}{\z@}{-3.5ex plus-1ex minus - -.2ex}{2.3ex plus.2ex}{\reset@font\large\bf}} - hooks/post-receive --