Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 59959 invoked from network); 8 Jul 2008 21:27:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Jul 2008 21:27:23 -0000 Received: (qmail 88465 invoked by uid 500); 8 Jul 2008 21:27:23 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 88450 invoked by uid 500); 8 Jul 2008 21:27:23 -0000 Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-dev@hadoop.apache.org Delivered-To: mailing list core-dev@hadoop.apache.org Received: (qmail 88435 invoked by uid 99); 8 Jul 2008 21:27:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Jul 2008 14:27:23 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Jul 2008 21:26:39 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id BBA02234C15E for ; Tue, 8 Jul 2008 14:26:31 -0700 (PDT) Message-ID: <1263364363.1215552391767.JavaMail.jira@brutus> Date: Tue, 8 Jul 2008 14:26:31 -0700 (PDT) From: "Pete Wyckoff (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Commented: (HADOOP-3485) implement writes In-Reply-To: <898585815.1212517844973.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HADOOP-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611808#action_12611808 ] Pete Wyckoff commented on HADOOP-3485: -------------------------------------- FUSE/Java FileOutputStream is causing the close to happen right after the create. I don't know which. Here's the output from fuse running in debug mode: [junit] unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 [junit] INIT: 7.8 [junit] flags=0x00000003 [junit] max_readahead=0x00020000 [junit] INIT: 7.8 [junit] flags=0x00000001 [junit] max_readahead=0x00020000 [junit] max_write=0x00020000 [junit] unique: 1, error: 0 (Success), outsize: 40 [junit] unique: 2, opcode: LOOKUP (1), nodeid: 1, insize: 50 [junit] LOOKUP /hello.txt [junit] unique: 2, error: -2 (No such file or directory), outsize: 16 [junit] unique: 3, opcode: MKNOD (8), nodeid: 1, insize: 58 [junit] MKNOD /hello.txt [junit] in dfs_create! NODEID: 2 [junit] dfs_release unique: 3, error: 0 (Success), outsize: 136 [junit] unique: 4, opcode: OPEN (14), nodeid: 2, insize: 48 [junit] unique: 4, error: 0 (Success), outsize: 32 [junit] OPEN[12151664] flags: 0x8401 /hello.txt [junit] unique: 5, opcode: WRITE (16), nodeid: 2, insize: 75 [junit] WRITE[12151664] 11 bytes to 0 [junit] WRITE[12151664] 11 bytes [junit] unique: 5, error: 0 (Success), outsize: 24 [junit] unique: 6, opcode: FLUSH (25), nodeid: 2, insize: 64 [junit] FLUSH[12151664] [junit] unique: 6, error: 0 (Success), outsize: 16 [junit] unique: 7, opcode: RELEASE (18), nodeid: 2, insize: 64 [junit] RELEASE[12151664] flags: 0x8401 And here's the java code creating the file: // create the file File file = new File(mpoint, "hello.txt"); FileOutputStream f = new FileOutputStream(file); String s = "hello world"; f.write(s.getBytes()); f.flush(); f.close(); > implement writes > ---------------- > > Key: HADOOP-3485 > URL: https://issues.apache.org/jira/browse/HADOOP-3485 > Project: Hadoop Core > Issue Type: New Feature > Components: contrib/fuse-dfs > Reporter: Pete Wyckoff > Priority: Minor > Attachments: patch1.txt > > Original Estimate: 48h > Remaining Estimate: 48h > > Doesn't support writes because fuse protocol first creates the file then closes it and re-opens it to start writing to it. So, (until hadoop-1700), we need a work around. > One way to do this is to open the file with overwrite flag on the second open. For security, would only want to do this for zero length files (could even check the creation ts too, but because of clock skew, that may be harder). > Doug, Craig, Nicholas - Comments? > -- pete > ps since mostly already implemented, this should be a very quick patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.