Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Wed, 16 Dec 2015 22:35:46 +0000 (UTC)
From: "Vinod Kumar Vavilapalli (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12919758.1449506088000.46694.1450305346702@Atlassian.JIRA>
In-Reply-To: <JIRA.12919758.1449506088000@Atlassian.JIRA>
References: <JIRA.12919758.1449506088000@Atlassian.JIRA>
 <JIRA.12919758.1449506088285@arcas>
Subject: [jira] [Updated] (HDFS-9516) truncate file fails with data dirs on
 multiple disks
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/HDFS-9516?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vinod Kumar Vavilapalli updated HDFS-9516:
------------------------------------------
    Target Version/s: 2.8.0, 2.7.3

[~shv], unfortunately this came in too late for 2.7.2. That said, I don=E2=
=80=99t see any reason why this shouldn=E2=80=99t be in 2.8.0 and 2.7.3. Se=
tting the target-versions accordingly on JIRA.

If you agree, appreciate backport help to those branches (branch-2.8.0, bra=
nch-2.7).


> truncate file fails with data dirs on multiple disks
> ----------------------------------------------------
>
>                 Key: HDFS-9516
>                 URL: https://issues.apache.org/jira/browse/HDFS-9516
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: datanode
>    Affects Versions: 2.7.1
>            Reporter: Bogdan Raducanu
>            Assignee: Plamen Jeliazkov
>             Fix For: 2.9.0
>
>         Attachments: HDFS-9516_1.patch, HDFS-9516_2.patch, HDFS-9516_3.pa=
tch, HDFS-9516_testFailures.patch, Main.java, truncate.dn.log
>
>
> FileSystem.truncate returns false (no exception) but the file is never cl=
osed and not writable after this.
> It seems to be because of copy on truncate which is used because the syst=
em is in upgrade state. In this case a rename between devices is attempted.
> See attached log and repro code.
> Probably also affects truncate snapshotted file when copy on truncate is =
also used.
> Possibly it affects not only truncate but any block recovery.
> I think the problem is in updateReplicaUnderRecovery
> {code}
> ReplicaBeingWritten newReplicaInfo =3D new ReplicaBeingWritten(
>             newBlockId, recoveryId, rur.getVolume(), blockFile.getParentF=
ile(),
>             newlength);
> {code}
> blockFile is created with copyReplicaWithNewBlockIdAndGS which is allowed=
 to choose any volume so rur.getVolume() is not where the block is located.
> =20


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)