[jira] Commented: (HDFS-200) In HDFS, sync() not yet guarantees data available to the new readers
[ https://issues.apache.org/jira/browse/HDFS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753443#action_12753443 ] stack commented on HDFS-200: @dhruba Did you get a chance to checkout Ryan's postings? Good stuff... > In HDFS, sync() not yet guarantees data available to the new readers > > > Key: HDFS-200 > URL: https://issues.apache.org/jira/browse/HDFS-200 > Project: Hadoop HDFS > Issue Type: New Feature >Reporter: Tsz Wo (Nicholas), SZE >Assignee: dhruba borthakur >Priority: Blocker > Attachments: 4379_20081010TC3.java, fsyncConcurrentReaders.txt, > fsyncConcurrentReaders11_20.txt, fsyncConcurrentReaders12_20.txt, > fsyncConcurrentReaders13_20.txt, fsyncConcurrentReaders14_20.txt, > fsyncConcurrentReaders3.patch, fsyncConcurrentReaders4.patch, > fsyncConcurrentReaders5.txt, fsyncConcurrentReaders6.patch, > fsyncConcurrentReaders9.patch, > hadoop-stack-namenode-aa0-000-12.u.powerset.com.log.gz, > hdfs-200-ryan-existing-file-fail.txt, hypertable-namenode.log.gz, > namenode.log, namenode.log, Reader.java, Reader.java, reopen_test.sh, > ReopenProblem.java, Writer.java, Writer.java > > > In the append design doc > (https://issues.apache.org/jira/secure/attachment/12370562/Appends.doc), it > says > * A reader is guaranteed to be able to read data that was 'flushed' before > the reader opened the file > However, this feature is not yet implemented. Note that the operation > 'flushed' is now called "sync". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HDFS-610) Add support for FileContext
Add support for FileContext --- Key: HDFS-610 URL: https://issues.apache.org/jira/browse/HDFS-610 Project: Hadoop HDFS Issue Type: New Feature Components: hdfs client, name-node Affects Versions: 0.21.0 Reporter: Sanjay Radia Assignee: Sanjay Radia Add support for FileContext (linked jira) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-601) TestBlockReport should obtain data directories from MiniHDFSCluster
[ https://issues.apache.org/jira/browse/HDFS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753410#action_12753410 ] Hadoop QA commented on HDFS-601: -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12418967/HDFS-601.patch against trunk revision 813101. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/20/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/20/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/20/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/20/console This message is automatically generated. > TestBlockReport should obtain data directories from MiniHDFSCluster > --- > > Key: HDFS-601 > URL: https://issues.apache.org/jira/browse/HDFS-601 > Project: Hadoop HDFS > Issue Type: Bug > Components: test >Affects Versions: 0.21.0, Append Branch >Reporter: Konstantin Shvachko >Assignee: Konstantin Boudnik > Fix For: 0.21.0, Append Branch > > Attachments: HDFS-601.patch, HDFS-601.patch > > > TestBlockReport relies on that "test.build.data" property is set in > configuration, which is not always correct, e.g. when you run test from > eclipse. It would be better to get data directories directly from the > mini-cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-606) ConcurrentModificationException in invalidateCorruptReplicas()
[
https://issues.apache.org/jira/browse/HDFS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753374#action_12753374
]
Jakob Homan commented on HDFS-606:
--
+1. Looks good.
> ConcurrentModificationException in invalidateCorruptReplicas()
> --
>
> Key: HDFS-606
> URL: https://issues.apache.org/jira/browse/HDFS-606
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
>Affects Versions: 0.21.0
>Reporter: Konstantin Shvachko
>Assignee: Konstantin Shvachko
> Fix For: 0.21.0
>
> Attachments: CMEinCorruptReplicas.patch
>
>
> {{BlockManager.invalidateCorruptReplicas()}} iterates over
> DatanodeDescriptor-s while removing corrupt replicas from the descriptors.
> This causes {{ConcurrentModificationException}} if there is more than one
> replicas of the block. I ran into this exception debugging different
> scenarios in append, but it should be fixed in the trunk too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-601) TestBlockReport should obtain data directories from MiniHDFSCluster
[ https://issues.apache.org/jira/browse/HDFS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated HDFS-601: Status: Open (was: Patch Available) Need to re-apply the patch > TestBlockReport should obtain data directories from MiniHDFSCluster > --- > > Key: HDFS-601 > URL: https://issues.apache.org/jira/browse/HDFS-601 > Project: Hadoop HDFS > Issue Type: Bug > Components: test >Affects Versions: 0.21.0, Append Branch >Reporter: Konstantin Shvachko >Assignee: Konstantin Boudnik > Fix For: 0.21.0, Append Branch > > Attachments: HDFS-601.patch, HDFS-601.patch > > > TestBlockReport relies on that "test.build.data" property is set in > configuration, which is not always correct, e.g. when you run test from > eclipse. It would be better to get data directories directly from the > mini-cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-601) TestBlockReport should obtain data directories from MiniHDFSCluster
[ https://issues.apache.org/jira/browse/HDFS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated HDFS-601: Status: Patch Available (was: Open) The patch is already attached (for the trunk) > TestBlockReport should obtain data directories from MiniHDFSCluster > --- > > Key: HDFS-601 > URL: https://issues.apache.org/jira/browse/HDFS-601 > Project: Hadoop HDFS > Issue Type: Bug > Components: test >Affects Versions: 0.21.0, Append Branch >Reporter: Konstantin Shvachko >Assignee: Konstantin Boudnik > Fix For: 0.21.0, Append Branch > > Attachments: HDFS-601.patch, HDFS-601.patch > > > TestBlockReport relies on that "test.build.data" property is set in > configuration, which is not always correct, e.g. when you run test from > eclipse. It would be better to get data directories directly from the > mini-cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-608) BlockReceiver:receivePacket(): packet's header parsing logic is complicated. Refactoring will help w/ testing efforts
[ https://issues.apache.org/jira/browse/HDFS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753357#action_12753357 ] Konstantin Boudnik commented on HDFS-608: - After conversing with Konstantin and Raghu I've been convinced that the fix has to be applied on both sides - i.e. BlockReceiver and DFSClient - at the same time. Because the effort is likely to require quite a bit of testing efforts it seems to be impractical to undertake in before 0.21 (and append) are completed. Thus, it's going to be postponed until after 0.21 time frame. > BlockReceiver:receivePacket(): packet's header parsing logic is complicated. > Refactoring will help w/ testing efforts > - > > Key: HDFS-608 > URL: https://issues.apache.org/jira/browse/HDFS-608 > Project: Hadoop HDFS > Issue Type: Improvement >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Attachments: HDFS-608.patch > > > Current logic of getting an information from a packet header is kinda > complicated with all shifting along the internal data buffer back and forth. > Besides, an absence of clear API to access a packet header's information > makes pipeline testing effort (even with aspects' application) to be a very > complicated or even impossible. > It'd be very nice to have a separate data container which will keep all the > information about a packet header within and will initialized once when a new > packet is acquired. > In order to speed-up pipeline testing needed for append (HDFS-265) this > modification might implemented in three different states: > - introduce new header structure and refactor receivePacket() > - refactor readNextPacket so it it will acquire next packet in initialize its > header > - refactor the sender side to use the packet's header structure as the > receiver does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HDFS-608) BlockReceiver:receivePacket(): packet's header parsing logic is complicated. Refactoring will help w/ testing efforts
[ https://issues.apache.org/jira/browse/HDFS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik reassigned HDFS-608: --- Assignee: Konstantin Boudnik > BlockReceiver:receivePacket(): packet's header parsing logic is complicated. > Refactoring will help w/ testing efforts > - > > Key: HDFS-608 > URL: https://issues.apache.org/jira/browse/HDFS-608 > Project: Hadoop HDFS > Issue Type: Improvement >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Attachments: HDFS-608.patch > > > Current logic of getting an information from a packet header is kinda > complicated with all shifting along the internal data buffer back and forth. > Besides, an absence of clear API to access a packet header's information > makes pipeline testing effort (even with aspects' application) to be a very > complicated or even impossible. > It'd be very nice to have a separate data container which will keep all the > information about a packet header within and will initialized once when a new > packet is acquired. > In order to speed-up pipeline testing needed for append (HDFS-265) this > modification might implemented in three different states: > - introduce new header structure and refactor receivePacket() > - refactor readNextPacket so it it will acquire next packet in initialize its > header > - refactor the sender side to use the packet's header structure as the > receiver does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-585) Datanode should serve up to visible length of a replica for read requests
[ https://issues.apache.org/jira/browse/HDFS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753354#action_12753354 ] Hairong Kuang commented on HDFS-585: Should BlockSender handle the case when visible length is -1? Otherwise, the patch looks good. > Datanode should serve up to visible length of a replica for read requests > - > > Key: HDFS-585 > URL: https://issues.apache.org/jira/browse/HDFS-585 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: data-node >Affects Versions: Append Branch >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: Append Branch > > Attachments: h585_20090903.patch, h585_20090904.patch, > h585_20090904b.patch, h585_20090909.patch, h585_20090909b.patch > > > As a part of the design in HDFS-265, datanodes should return all bytes within > the visible length of a replica to the DFSClient in order to support read > consistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-503) Implement erasure coding as a layer on HDFS
[ https://issues.apache.org/jira/browse/HDFS-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753349#action_12753349 ] Raghu Angadi commented on HDFS-503: --- This seems pretty useful. since this is done outside HDFS, it is simpler for users to start experimenting. Say a file has 5 blocks with replication of 3 : total 15 blocks With this tool, replication could be reduced to 2, with one block for parity : total 10 + 2 blocks This is a savings of 20% space. Is this math correct? Detecting when to 'unRaid' : * The patch does this using a wrapper filesystem over HDFS. ** This requires file to be read by the client. ** More often than not, HDFS knows about irrecoverable blocks much before a client reads. ** this only semi-transparent to the users since they have to use the new filesystem. * Another completely transparent alternative could be to make 'RaidNode' ping NameNode for missing blocks. ** NameNode already knows about blocks that don't have any known good replica. And fetching that list is cheap. ** RaidNode could check if the corrupt/missing block belongs to any of its files. ** Rest of RaidNode pretty much remains the same as this patch. > Implement erasure coding as a layer on HDFS > --- > > Key: HDFS-503 > URL: https://issues.apache.org/jira/browse/HDFS-503 > Project: Hadoop HDFS > Issue Type: New Feature >Reporter: dhruba borthakur >Assignee: dhruba borthakur > Attachments: raid1.txt > > > The goal of this JIRA is to discuss how the cost of raw storage for a HDFS > file system can be reduced. Keeping three copies of the same data is very > costly, especially when the size of storage is huge. One idea is to reduce > the replication factor and do erasure coding of a set of blocks so that the > over probability of failure of a block remains the same as before. > Many forms of error-correcting codes are available, see > http://en.wikipedia.org/wiki/Erasure_code. Also, recent research from CMU has > described DiskReduce > https://opencirrus.org/system/files/Gibson-OpenCirrus-June9-09.ppt. > My opinion is to discuss implementation strategies that are not part of base > HDFS, but is a layer on top of HDFS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HDFS-609) Create a file with the append flag does not work in HDFS
Create a file with the append flag does not work in HDFS Key: HDFS-609 URL: https://issues.apache.org/jira/browse/HDFS-609 Project: Hadoop HDFS Issue Type: Bug Affects Versions: 0.21.0 Reporter: Hairong Kuang Priority: Blocker Fix For: 0.21.0 HADOOP-5438 introduced a create API with flags. There are a couple of issues when the flag is set to be APPEND. 1. The APPEND flag does not work in HDFS. Append is not as simple as changing a FileINode to be a FileINodeUnderConstruction. It also need to reopen the last block for applend if last block is not full and handle crc when the last crc chunk is not full. 2. The API is not well thought. It has parameters like replication factor and blockSize. Those parameters do not make any sense if APPEND flag is set. But they give an application user a wrong impression that append could change a file's block size and replication factor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-604) Block report processing for append
[ https://issues.apache.org/jira/browse/HDFS-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753344#action_12753344 ] Hairong Kuang commented on HDFS-604: 1. When a block is under construction, a block report should not update an existing replica's state or add a replica to toRemoved list. NN should only allow to add new replicas. Otherwise, it will have race condition with client updated pipeline. 2. NN should not add storedBlock to toCorrupt list if storedBlock' GS is not the same as that of the reported replica. Otherwise a wrong GS of the replica will get deleted. Other issues we have discussed: 1. When fetching stored block, GS should not be part of the key. HDFS-512 is not committed yet. 2. For safemode, we should count only complete blocks and finalized replicas. > Block report processing for append > -- > > Key: HDFS-604 > URL: https://issues.apache.org/jira/browse/HDFS-604 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: name-node >Affects Versions: Append Branch >Reporter: Konstantin Shvachko >Assignee: Konstantin Shvachko > Fix For: Append Branch > > Attachments: BlockReportNN.patch, BlockReportNN.patch > > > Implement new block report processing on the name-node as stated in the > append design and HDFS-576. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-585) Datanode should serve up to visible length of a replica for read requests
[ https://issues.apache.org/jira/browse/HDFS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HDFS-585: Attachment: h585_20090909b.patch h585_20090909b.patch: increased the waiting time to 3 seconds since HdfsConstants.READ_TIMEOUT = 60 * 1000 . > Datanode should serve up to visible length of a replica for read requests > - > > Key: HDFS-585 > URL: https://issues.apache.org/jira/browse/HDFS-585 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: data-node >Affects Versions: Append Branch >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: Append Branch > > Attachments: h585_20090903.patch, h585_20090904.patch, > h585_20090904b.patch, h585_20090909.patch, h585_20090909b.patch > > > As a part of the design in HDFS-265, datanodes should return all bytes within > the visible length of a replica to the DFSClient in order to support read > consistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-608) BlockReceiver:receivePacket(): packet's header parsing logic is complicated. Refactoring will help w/ testing efforts
[
https://issues.apache.org/jira/browse/HDFS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Boudnik updated HDFS-608:
Attachment: HDFS-608.patch
The patch provides the fix for the first step of the refactoring in the
receivePacket().
{{test-core}} has passed without any problems.
Please review.
> BlockReceiver:receivePacket(): packet's header parsing logic is complicated.
> Refactoring will help w/ testing efforts
> -
>
> Key: HDFS-608
> URL: https://issues.apache.org/jira/browse/HDFS-608
> Project: Hadoop HDFS
> Issue Type: Improvement
>Reporter: Konstantin Boudnik
> Attachments: HDFS-608.patch
>
>
> Current logic of getting an information from a packet header is kinda
> complicated with all shifting along the internal data buffer back and forth.
> Besides, an absence of clear API to access a packet header's information
> makes pipeline testing effort (even with aspects' application) to be a very
> complicated or even impossible.
> It'd be very nice to have a separate data container which will keep all the
> information about a packet header within and will initialized once when a new
> packet is acquired.
> In order to speed-up pipeline testing needed for append (HDFS-265) this
> modification might implemented in three different states:
> - introduce new header structure and refactor receivePacket()
> - refactor readNextPacket so it it will acquire next packet in initialize its
> header
> - refactor the sender side to use the packet's header structure as the
> receiver does.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-599) Improve Namenode robustness by prioritizing datanode heartbeats over client requests
[ https://issues.apache.org/jira/browse/HDFS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753312#action_12753312 ] Allen Wittenauer commented on HDFS-599: --- Hong, you can still implement queue based regardless of whether multiple ports are used. The reverse is not true. > Improve Namenode robustness by prioritizing datanode heartbeats over client > requests > > > Key: HDFS-599 > URL: https://issues.apache.org/jira/browse/HDFS-599 > Project: Hadoop HDFS > Issue Type: Improvement > Components: name-node >Reporter: dhruba borthakur >Assignee: dhruba borthakur > > The namenode processes RPC requests from clients that are reading/writing to > files as well as heartbeats/block reports from datanodes. > Sometime, because of various reasons (Java GC runs, inconsistent performance > of NFS filer that stores HDFS transacttion logs, etc), the namenode > encounters transient slowness. For example, if the device that stores the > HDFS transaction logs becomes sluggish, the Namenode's ability to process > RPCs slows down to a certain extent. During this time, the RPCs from clients > as well as the RPCs from datanodes suffer in similar fashion. If the > underlying problem becomes worse, the NN's ability to process a heartbeat > from a DN is severly impacted, thus causing the NN to declare that the DN is > dead. Then the NN starts replicating blocks that used to reside on the > now-declared-dead datanode. This adds extra load to the NN. Then the > now-declared-datanode finally re-establishes contact with the NN, and sends a > block report. The block report processing on the NN is another heavyweight > activity, thus casing more load to the already overloaded namenode. > My proposal is tha the NN should try its best to continue processing RPCs > from datanodes and give lesser priority to serving client requests. The > Datanode RPCs are integral to the consistency and performance of the Hadoop > file system, and it is better to protect it at all costs. This will ensure > that NN recovers from the hiccup much faster than what it does now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HDFS-608) BlockReceiver:receivePacket(): packet's header parsing logic is complicated. Refactoring will help w/ testing efforts
BlockReceiver:receivePacket(): packet's header parsing logic is complicated. Refactoring will help w/ testing efforts - Key: HDFS-608 URL: https://issues.apache.org/jira/browse/HDFS-608 Project: Hadoop HDFS Issue Type: Improvement Reporter: Konstantin Boudnik Current logic of getting an information from a packet header is kinda complicated with all shifting along the internal data buffer back and forth. Besides, an absence of clear API to access a packet header's information makes pipeline testing effort (even with aspects' application) to be a very complicated or even impossible. It'd be very nice to have a separate data container which will keep all the information about a packet header within and will initialized once when a new packet is acquired. In order to speed-up pipeline testing needed for append (HDFS-265) this modification might implemented in three different states: - introduce new header structure and refactor receivePacket() - refactor readNextPacket so it it will acquire next packet in initialize its header - refactor the sender side to use the packet's header structure as the receiver does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-585) Datanode should serve up to visible length of a replica for read requests
[ https://issues.apache.org/jira/browse/HDFS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HDFS-585: Attachment: h585_20090909.patch h585_20090909.patch: use getBytesOnDisk() instead of file length. > 2. Should we have unit tests testing reading from an unclosed file? The read function is not yet completed. So it is hard to write unit tests for this. If you insist, I don't mind to spend time on adding unit tests. > Datanode should serve up to visible length of a replica for read requests > - > > Key: HDFS-585 > URL: https://issues.apache.org/jira/browse/HDFS-585 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: data-node >Affects Versions: Append Branch >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: Append Branch > > Attachments: h585_20090903.patch, h585_20090904.patch, > h585_20090904b.patch, h585_20090909.patch > > > As a part of the design in HDFS-265, datanodes should return all bytes within > the visible length of a replica to the DFSClient in order to support read > consistency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-604) Block report processing for append
[ https://issues.apache.org/jira/browse/HDFS-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Shvachko updated HDFS-604: - Attachment: BlockReportNN.patch Sorry wrong version of the patch. > Block report processing for append > -- > > Key: HDFS-604 > URL: https://issues.apache.org/jira/browse/HDFS-604 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: name-node >Affects Versions: Append Branch >Reporter: Konstantin Shvachko >Assignee: Konstantin Shvachko > Fix For: Append Branch > > Attachments: BlockReportNN.patch, BlockReportNN.patch > > > Implement new block report processing on the name-node as stated in the > append design and HDFS-576. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-235) Add support for byte-ranges to hftp
[ https://issues.apache.org/jira/browse/HDFS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753268#action_12753268 ] Tsz Wo (Nicholas), SZE commented on HDFS-235: - The committed patch has quite a few warnings: - Enumeration is a raw type. References to generic type Enumeration should be parameterized StreamFile.java src/java/org/apache/hadoop/hdfs/server/namenode line 70 Java Problem - The field TestByteRangeInputStream.LOG is never read locally TestByteRangeInputStream.java src/test/hdfs/org/apache/hadoop/hdfsline 108Java Problem - Enumeration is a raw type. References to generic type Enumeration should be parameterized TestStreamFile.java src/test/hdfs/org/apache/hadoop/hdfs/server/namenodeline 236Java Problem (there are 10 warnings in TestStreamFile.java) > Add support for byte-ranges to hftp > --- > > Key: HDFS-235 > URL: https://issues.apache.org/jira/browse/HDFS-235 > Project: Hadoop HDFS > Issue Type: New Feature >Affects Versions: 0.21.0 >Reporter: Venkatesh S >Assignee: Bill Zeller > Fix For: 0.21.0 > > Attachments: hdfs-235-1.patch, hdfs-235-2.patch, hdfs-235-3.patch > > > Support should be similar to http byte-serving. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-605) There's not need to run fault-inject tests by 'run-test-hdfs-with-mr' target
[
https://issues.apache.org/jira/browse/HDFS-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753267#action_12753267
]
Hudson commented on HDFS-605:
-
Integrated in Hadoop-Hdfs-trunk-Commit #25 (See
[http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk-Commit/25/])
. Do not run fault injection tests in the run-test-hdfs-with-mr target.
Contributed by Konstantin Boudnik
> There's not need to run fault-inject tests by 'run-test-hdfs-with-mr' target
>
>
> Key: HDFS-605
> URL: https://issues.apache.org/jira/browse/HDFS-605
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: build, test
>Affects Versions: 0.21.0
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 0.21.0
>
> Attachments: HDFS-605.patch
>
>
> It turns out that running fault injection tests doesn't make any sense when
> {{run-test-hdfs-with-mr}} target is being executed. Thus, {{build.xml}} has
> to be modified.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HDFS-603) Most replica related classes cannot be accessed
[ https://issues.apache.org/jira/browse/HDFS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE resolved HDFS-603. - Resolution: Fixed I have committed this to the Append Branch. > Most replica related classes cannot be accessed > --- > > Key: HDFS-603 > URL: https://issues.apache.org/jira/browse/HDFS-603 > Project: Hadoop HDFS > Issue Type: Improvement > Components: data-node >Affects Versions: Append Branch >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: Append Branch > > Attachments: h603_20090908.patch, h603_20090909.patch > > > Currently, there are several replica related classes in > org.apache.hadoop.hdfs.server.datanode: > - ReplicaInfo > - ReplicaInPipelineInterface > - ReplicaInPipeline > - ReplicaUnderRecovery > - ReplicaWaitingToBeRecovered > - ReplicaBeingWritten > - FinalizedReplica > All these classes cannot be accessed above FSDatasetInterface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-606) ConcurrentModificationException in invalidateCorruptReplicas()
[
https://issues.apache.org/jira/browse/HDFS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753251#action_12753251
]
Hadoop QA commented on HDFS-606:
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12419013/CMEinCorruptReplicas.patch
against trunk revision 812701.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/19/testReport/
Findbugs warnings:
http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/19/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results:
http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/19/artifact/trunk/build/test/checkstyle-errors.html
Console output:
http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h5.grid.sp2.yahoo.net/19/console
This message is automatically generated.
> ConcurrentModificationException in invalidateCorruptReplicas()
> --
>
> Key: HDFS-606
> URL: https://issues.apache.org/jira/browse/HDFS-606
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
>Affects Versions: 0.21.0
>Reporter: Konstantin Shvachko
>Assignee: Konstantin Shvachko
> Fix For: 0.21.0
>
> Attachments: CMEinCorruptReplicas.patch
>
>
> {{BlockManager.invalidateCorruptReplicas()}} iterates over
> DatanodeDescriptor-s while removing corrupt replicas from the descriptors.
> This causes {{ConcurrentModificationException}} if there is more than one
> replicas of the block. I ran into this exception debugging different
> scenarios in append, but it should be fixed in the trunk too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-531) Renaming of configuration keys
[ https://issues.apache.org/jira/browse/HDFS-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jitendra Nath Pandey updated HDFS-531: -- Attachment: unchanged_keys.txt unchanged_keys.txt file contains the keys that are assumed to be rightly named and will not be changed. > Renaming of configuration keys > -- > > Key: HDFS-531 > URL: https://issues.apache.org/jira/browse/HDFS-531 > Project: Hadoop HDFS > Issue Type: Improvement >Reporter: Jitendra Nath Pandey >Assignee: Jitendra Nath Pandey > Fix For: 0.21.0 > > Attachments: changed_config_keys.2.txt, changed_config_keys.txt, > unchanged_keys.txt > > > Keys in configuration files should be standardized so that key names reflect > the components they are used in. > For example: >dfs.backup.address should be renamed to dfs.namenode.backup.address >dfs.data.dir should be renamed to dfs.datanode.data.dir > This change will impact both hdfs and common sources. > Following convention is proposed: > 1. Any key related hdfs should begin with 'dfs'. > 2. Any key related to namenode, datanode or client should begin with > dfs.namenode, dfs.datanode or dfs.client respectively. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-603) Most replica related classes cannot be accessed
[ https://issues.apache.org/jira/browse/HDFS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HDFS-603: Assignee: Tsz Wo (Nicholas), SZE Hadoop Flags: [Reviewed] > Most replica related classes cannot be accessed > --- > > Key: HDFS-603 > URL: https://issues.apache.org/jira/browse/HDFS-603 > Project: Hadoop HDFS > Issue Type: Improvement > Components: data-node >Affects Versions: Append Branch >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: Append Branch > > Attachments: h603_20090908.patch, h603_20090909.patch > > > Currently, there are several replica related classes in > org.apache.hadoop.hdfs.server.datanode: > - ReplicaInfo > - ReplicaInPipelineInterface > - ReplicaInPipeline > - ReplicaUnderRecovery > - ReplicaWaitingToBeRecovered > - ReplicaBeingWritten > - FinalizedReplica > All these classes cannot be accessed above FSDatasetInterface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-605) There's not need to run fault-inject tests by 'run-test-hdfs-with-mr' target
[
https://issues.apache.org/jira/browse/HDFS-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsz Wo (Nicholas), SZE updated HDFS-605:
Resolution: Fixed
Status: Resolved (was: Patch Available)
I have committed this. Thanks, Cos!
> There's not need to run fault-inject tests by 'run-test-hdfs-with-mr' target
>
>
> Key: HDFS-605
> URL: https://issues.apache.org/jira/browse/HDFS-605
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: build, test
>Affects Versions: 0.21.0
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 0.21.0
>
> Attachments: HDFS-605.patch
>
>
> It turns out that running fault injection tests doesn't make any sense when
> {{run-test-hdfs-with-mr}} target is being executed. Thus, {{build.xml}} has
> to be modified.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-599) Improve Namenode robustness by prioritizing datanode heartbeats over client requests
[ https://issues.apache.org/jira/browse/HDFS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753240#action_12753240 ] Hong Tang commented on HDFS-599: Using different ports for QoS also has its limitations. The request dispatching logic must be baked in the client side. Inside the server, multiple threads or multiple thread pools that handle different classes are oblivious to each other and may not enforce fine grain resource control.This OSDI paper (which I co-authored), http://www.usenix.org/events/osdi02/tech/shen.html, describes a complicated case of QoS policy and the solution is based on queues. Switches may be useful for network QoS (e.g. preventing DoS attacks and prioritize traffic). But for application level QoS (where the system is not constrained by the amount of network traffic, but the work needs to be performed in the server), then I'd think queue-based solution is better. > Improve Namenode robustness by prioritizing datanode heartbeats over client > requests > > > Key: HDFS-599 > URL: https://issues.apache.org/jira/browse/HDFS-599 > Project: Hadoop HDFS > Issue Type: Improvement > Components: name-node >Reporter: dhruba borthakur >Assignee: dhruba borthakur > > The namenode processes RPC requests from clients that are reading/writing to > files as well as heartbeats/block reports from datanodes. > Sometime, because of various reasons (Java GC runs, inconsistent performance > of NFS filer that stores HDFS transacttion logs, etc), the namenode > encounters transient slowness. For example, if the device that stores the > HDFS transaction logs becomes sluggish, the Namenode's ability to process > RPCs slows down to a certain extent. During this time, the RPCs from clients > as well as the RPCs from datanodes suffer in similar fashion. If the > underlying problem becomes worse, the NN's ability to process a heartbeat > from a DN is severly impacted, thus causing the NN to declare that the DN is > dead. Then the NN starts replicating blocks that used to reside on the > now-declared-dead datanode. This adds extra load to the NN. Then the > now-declared-datanode finally re-establishes contact with the NN, and sends a > block report. The block report processing on the NN is another heavyweight > activity, thus casing more load to the already overloaded namenode. > My proposal is tha the NN should try its best to continue processing RPCs > from datanodes and give lesser priority to serving client requests. The > Datanode RPCs are integral to the consistency and performance of the Hadoop > file system, and it is better to protect it at all costs. This will ensure > that NN recovers from the hiccup much faster than what it does now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-603) Most replica related classes cannot be accessed
[
https://issues.apache.org/jira/browse/HDFS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753239#action_12753239
]
Tsz Wo (Nicholas), SZE commented on HDFS-603:
-
{noformat}
[exec] +1 overall.
[exec]
[exec] +1 @author. The patch does not contain any @author tags.
[exec]
[exec] +1 tests included. The patch appears to include 6 new or modified
tests.
[exec]
[exec] +1 javadoc. The javadoc tool did not generate any warning messages.
[exec]
[exec] +1 javac. The applied patch does not increase the total number of
javac compiler warnings.
[exec]
[exec] +1 findbugs. The patch does not introduce any new Findbugs warnings.
[exec]
[exec] +1 release audit. The applied patch does not increase the total
number of release audit warnings.
{noformat}
Passed all the tests this time. Note that the patch does not fix TestBackupNode.
> Most replica related classes cannot be accessed
> ---
>
> Key: HDFS-603
> URL: https://issues.apache.org/jira/browse/HDFS-603
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: data-node
>Affects Versions: Append Branch
>Reporter: Tsz Wo (Nicholas), SZE
> Fix For: Append Branch
>
> Attachments: h603_20090908.patch, h603_20090909.patch
>
>
> Currently, there are several replica related classes in
> org.apache.hadoop.hdfs.server.datanode:
> - ReplicaInfo
> - ReplicaInPipelineInterface
> - ReplicaInPipeline
> - ReplicaUnderRecovery
> - ReplicaWaitingToBeRecovered
> - ReplicaBeingWritten
> - FinalizedReplica
> All these classes cannot be accessed above FSDatasetInterface.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-550) DataNode restarts may introduce corrupt/duplicated/lost replicas when handling detached replicas
[ https://issues.apache.org/jira/browse/HDFS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753237#action_12753237 ] Hairong Kuang commented on HDFS-550: > The recovery code (at datanode restart time) first checks to see if the block > is already in current. The problem is that replicas are not in "current" normally. They are in the subdirs of "current". > DataNode restarts may introduce corrupt/duplicated/lost replicas when > handling detached replicas > > > Key: HDFS-550 > URL: https://issues.apache.org/jira/browse/HDFS-550 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: data-node >Affects Versions: 0.21.0 >Reporter: Hairong Kuang >Assignee: Hairong Kuang >Priority: Blocker > Fix For: Append Branch > > Attachments: detach.patch > > > Current trunk first calls detach to unlinks a finalized replica before > appending to this block. Unlink is done by temporally copying the block file > in the "current" subtree to a directory called "detach" under the volume's > daa directory and then copies it back when unlink succeeds. On datanode > restarts, datanodes recover faied unlink by copying replicas under "detach" > to "current". > There are two bugs with this implementation: > 1. The "detach" directory does not include in a snapshot. so rollback will > cause the "detaching" replicas to be lost. > 2. After a replica is copied to the "detach" directory, the information of > its original location is lost. The current implementation erroneously assumes > that the replica to be unlinked is under "current". This will make two > instances of replicas with the same block id to coexist in a datanode. Also > if a replica under "detach" is corrupt, the corrupt replica is moved to > "current" without being detected, polluting datanode data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-550) DataNode restarts may introduce corrupt/duplicated/lost replicas when handling detached replicas
[ https://issues.apache.org/jira/browse/HDFS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753233#action_12753233 ] dhruba borthakur commented on HDFS-550: --- The recovery code (at datanode restart time) first checks to see if the block is already in current. If not, it adds it to current. So, there can be only replica of that block in the "current" directory of the namenode. Another copy of the same block could also reside in the "snapshot" directory. Is that what you mean by "duplicate replicas on the same datanode"? > DataNode restarts may introduce corrupt/duplicated/lost replicas when > handling detached replicas > > > Key: HDFS-550 > URL: https://issues.apache.org/jira/browse/HDFS-550 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: data-node >Affects Versions: 0.21.0 >Reporter: Hairong Kuang >Assignee: Hairong Kuang >Priority: Blocker > Fix For: Append Branch > > Attachments: detach.patch > > > Current trunk first calls detach to unlinks a finalized replica before > appending to this block. Unlink is done by temporally copying the block file > in the "current" subtree to a directory called "detach" under the volume's > daa directory and then copies it back when unlink succeeds. On datanode > restarts, datanodes recover faied unlink by copying replicas under "detach" > to "current". > There are two bugs with this implementation: > 1. The "detach" directory does not include in a snapshot. so rollback will > cause the "detaching" replicas to be lost. > 2. After a replica is copied to the "detach" directory, the information of > its original location is lost. The current implementation erroneously assumes > that the replica to be unlinked is under "current". This will make two > instances of replicas with the same block id to coexist in a datanode. Also > if a replica under "detach" is corrupt, the corrupt replica is moved to > "current" without being detected, polluting datanode data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-599) Improve Namenode robustness by prioritizing datanode heartbeats over client requests
[ https://issues.apache.org/jira/browse/HDFS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753235#action_12753235 ] Philip Zeyliger commented on HDFS-599: -- In my experience, using different ports for QoS turns out to be compelling because you can tell fancy-pants switches to prioritize traffic at port X over traffic at port Y, but it's harder (or impossible) to get a switch to prioritize based on what's in the packet itself. Perhaps Hadoop could be largely agnostic over which of a handful of open ports data is coming in, relying on the authorization layer to kick out client requests on a port that's supposed to be only for elevated-priority requests. > Improve Namenode robustness by prioritizing datanode heartbeats over client > requests > > > Key: HDFS-599 > URL: https://issues.apache.org/jira/browse/HDFS-599 > Project: Hadoop HDFS > Issue Type: Improvement > Components: name-node >Reporter: dhruba borthakur >Assignee: dhruba borthakur > > The namenode processes RPC requests from clients that are reading/writing to > files as well as heartbeats/block reports from datanodes. > Sometime, because of various reasons (Java GC runs, inconsistent performance > of NFS filer that stores HDFS transacttion logs, etc), the namenode > encounters transient slowness. For example, if the device that stores the > HDFS transaction logs becomes sluggish, the Namenode's ability to process > RPCs slows down to a certain extent. During this time, the RPCs from clients > as well as the RPCs from datanodes suffer in similar fashion. If the > underlying problem becomes worse, the NN's ability to process a heartbeat > from a DN is severly impacted, thus causing the NN to declare that the DN is > dead. Then the NN starts replicating blocks that used to reside on the > now-declared-dead datanode. This adds extra load to the NN. Then the > now-declared-datanode finally re-establishes contact with the NN, and sends a > block report. The block report processing on the NN is another heavyweight > activity, thus casing more load to the already overloaded namenode. > My proposal is tha the NN should try its best to continue processing RPCs > from datanodes and give lesser priority to serving client requests. The > Datanode RPCs are integral to the consistency and performance of the Hadoop > file system, and it is better to protect it at all costs. This will ensure > that NN recovers from the hiccup much faster than what it does now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-599) Improve Namenode robustness by prioritizing datanode heartbeats over client requests
[ https://issues.apache.org/jira/browse/HDFS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753231#action_12753231 ] dhruba borthakur commented on HDFS-599: --- > A different port may be a good way to implement this. I will go ahead and implement this one. I will make the javadocs and messages very explicit in warning the advanced adminstrator about the possible pitfalls of opening a new port. Does that sound reasonable to you Konstantin? > Improve Namenode robustness by prioritizing datanode heartbeats over client > requests > > > Key: HDFS-599 > URL: https://issues.apache.org/jira/browse/HDFS-599 > Project: Hadoop HDFS > Issue Type: Improvement > Components: name-node >Reporter: dhruba borthakur >Assignee: dhruba borthakur > > The namenode processes RPC requests from clients that are reading/writing to > files as well as heartbeats/block reports from datanodes. > Sometime, because of various reasons (Java GC runs, inconsistent performance > of NFS filer that stores HDFS transacttion logs, etc), the namenode > encounters transient slowness. For example, if the device that stores the > HDFS transaction logs becomes sluggish, the Namenode's ability to process > RPCs slows down to a certain extent. During this time, the RPCs from clients > as well as the RPCs from datanodes suffer in similar fashion. If the > underlying problem becomes worse, the NN's ability to process a heartbeat > from a DN is severly impacted, thus causing the NN to declare that the DN is > dead. Then the NN starts replicating blocks that used to reside on the > now-declared-dead datanode. This adds extra load to the NN. Then the > now-declared-datanode finally re-establishes contact with the NN, and sends a > block report. The block report processing on the NN is another heavyweight > activity, thus casing more load to the already overloaded namenode. > My proposal is tha the NN should try its best to continue processing RPCs > from datanodes and give lesser priority to serving client requests. The > Datanode RPCs are integral to the consistency and performance of the Hadoop > file system, and it is better to protect it at all costs. This will ensure > that NN recovers from the hiccup much faster than what it does now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HDFS-607) HDFS should support SNMP
HDFS should support SNMP Key: HDFS-607 URL: https://issues.apache.org/jira/browse/HDFS-607 Project: Hadoop HDFS Issue Type: New Feature Reporter: Allen Wittenauer HDFS should provide key statistics over a standard protocol such as SNMP. This would allow for much easier integration into common software packages that are already established in the industry. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-607) HDFS should support SNMP
[ https://issues.apache.org/jira/browse/HDFS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753230#action_12753230 ] Allen Wittenauer commented on HDFS-607: --- For example, disk space usage could be trended via Zenoss much the same way we trend CPU utilization. > HDFS should support SNMP > > > Key: HDFS-607 > URL: https://issues.apache.org/jira/browse/HDFS-607 > Project: Hadoop HDFS > Issue Type: New Feature >Reporter: Allen Wittenauer > > HDFS should provide key statistics over a standard protocol such as SNMP. > This would allow for much easier integration into common software packages > that are already established in the industry. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-599) Improve Namenode robustness by prioritizing datanode heartbeats over client requests
[ https://issues.apache.org/jira/browse/HDFS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753229#action_12753229 ] Doug Cutting commented on HDFS-599: --- A different port may be a good way to implement this. But it's worth noting that Hadoop already probably uses too many ports, and, long-term, we should probably aim to use fewer and rely instead more on authentication and authorization of requests. For example, we might use HTTP for all interactions, including RPC, shuffle, and datanode access. The primary weakness of HTTP for this is that it requires that responses over a reused connection arrive in-order, while Hadoop's RPC permits out-of-order responses over a reused connection. Even this might be worked around if we used a chunked encoding where requests and responses are sent as chunks whose chunk headers include the request ID. > Improve Namenode robustness by prioritizing datanode heartbeats over client > requests > > > Key: HDFS-599 > URL: https://issues.apache.org/jira/browse/HDFS-599 > Project: Hadoop HDFS > Issue Type: Improvement > Components: name-node >Reporter: dhruba borthakur >Assignee: dhruba borthakur > > The namenode processes RPC requests from clients that are reading/writing to > files as well as heartbeats/block reports from datanodes. > Sometime, because of various reasons (Java GC runs, inconsistent performance > of NFS filer that stores HDFS transacttion logs, etc), the namenode > encounters transient slowness. For example, if the device that stores the > HDFS transaction logs becomes sluggish, the Namenode's ability to process > RPCs slows down to a certain extent. During this time, the RPCs from clients > as well as the RPCs from datanodes suffer in similar fashion. If the > underlying problem becomes worse, the NN's ability to process a heartbeat > from a DN is severly impacted, thus causing the NN to declare that the DN is > dead. Then the NN starts replicating blocks that used to reside on the > now-declared-dead datanode. This adds extra load to the NN. Then the > now-declared-datanode finally re-establishes contact with the NN, and sends a > block report. The block report processing on the NN is another heavyweight > activity, thus casing more load to the already overloaded namenode. > My proposal is tha the NN should try its best to continue processing RPCs > from datanodes and give lesser priority to serving client requests. The > Datanode RPCs are integral to the consistency and performance of the Hadoop > file system, and it is better to protect it at all costs. This will ensure > that NN recovers from the hiccup much faster than what it does now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-599) Improve Namenode robustness by prioritizing datanode heartbeats over client requests
[ https://issues.apache.org/jira/browse/HDFS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753217#action_12753217 ] dhruba borthakur commented on HDFS-599: --- > It is about an increment in number of gates from an attack can't be mounted. > That's why I've referred to the 'surface' Agreed. An administrator who switches on non-default semantics (i.e. using additional server port) without evaluating the corresponding security impact would suffer :-) > Would it be possible in a future to have some cluster nodes outside of one's > firewall? Good point. almost anything and everything is possible in the fuure. Maybe we can address it via proper documentation and warning messages. > Improve Namenode robustness by prioritizing datanode heartbeats over client > requests > > > Key: HDFS-599 > URL: https://issues.apache.org/jira/browse/HDFS-599 > Project: Hadoop HDFS > Issue Type: Improvement > Components: name-node >Reporter: dhruba borthakur >Assignee: dhruba borthakur > > The namenode processes RPC requests from clients that are reading/writing to > files as well as heartbeats/block reports from datanodes. > Sometime, because of various reasons (Java GC runs, inconsistent performance > of NFS filer that stores HDFS transacttion logs, etc), the namenode > encounters transient slowness. For example, if the device that stores the > HDFS transaction logs becomes sluggish, the Namenode's ability to process > RPCs slows down to a certain extent. During this time, the RPCs from clients > as well as the RPCs from datanodes suffer in similar fashion. If the > underlying problem becomes worse, the NN's ability to process a heartbeat > from a DN is severly impacted, thus causing the NN to declare that the DN is > dead. Then the NN starts replicating blocks that used to reside on the > now-declared-dead datanode. This adds extra load to the NN. Then the > now-declared-datanode finally re-establishes contact with the NN, and sends a > block report. The block report processing on the NN is another heavyweight > activity, thus casing more load to the already overloaded namenode. > My proposal is tha the NN should try its best to continue processing RPCs > from datanodes and give lesser priority to serving client requests. The > Datanode RPCs are integral to the consistency and performance of the Hadoop > file system, and it is better to protect it at all costs. This will ensure > that NN recovers from the hiccup much faster than what it does now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-202) Add a bulk FIleSystem.getFileBlockLocations
[ https://issues.apache.org/jira/browse/HDFS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753215#action_12753215 ] Doug Cutting commented on HDFS-202: --- > Is the optimization for sending only partial block reports really necessary? It may help the append-savvy distcp use case, but is not in the mapred job submission use case. Even in the append-savvy distcp use case, it's not clear that it's required. Maybe we should punt that until someone develops an append-savvy distcp? > Why not create a class called DetailedFileStatus which contains both the file > status and block locations: Why is DetailedFileStatus[] better than Map? The latter seems more transparent. > DetailedFileStatus[] = getBlockLocations(Path[] paths); // 1:1 mapping > between the two arrays as Doug suggested. That was intended for the append-savvy distcp use case. The original use case was for mapred job submission, where we typically have a list of directories. With directories there is not a 1:1 mapping. > Add a bulk FIleSystem.getFileBlockLocations > --- > > Key: HDFS-202 > URL: https://issues.apache.org/jira/browse/HDFS-202 > Project: Hadoop HDFS > Issue Type: New Feature >Reporter: Arun C Murthy >Assignee: Jakob Homan > > Currently map-reduce applications (specifically file-based input-formats) use > FileSystem.getFileBlockLocations to compute splits. However they are forced > to call it once per file. > The downsides are multiple: ># Even with a few thousand files to process the number of RPCs quickly > starts getting noticeable ># The current implementation of getFileBlockLocations is too slow since > each call results in 'search' in the namesystem. Assuming a few thousand > input files it results in that many RPCs and 'searches'. > It would be nice to have a FileSystem.getFileBlockLocations which can take in > a directory, and return the block-locations for all files in that directory. > We could eliminate both the per-file RPC and also the 'search' by a 'scan'. > When I tested this for terasort, a moderate job with 8000 input files the > runtime halved from the current 8s to 4s. Clearly this is much more important > for latency-sensitive applications... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-599) Improve Namenode robustness by prioritizing datanode heartbeats over client requests
[ https://issues.apache.org/jira/browse/HDFS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753214#action_12753214 ] Konstantin Boudnik commented on HDFS-599: - bq. Why would that be? ...the default setting would still be to use one single port for DatanodeProtocol and ClientProtocol, so it should not affect (security) for preliminary users Can the default configuration be changed by advanced users opening the second port? Perhaps. And because the single port is considered as the default configuration I can see how only the default one gets tested and the non-default one won't. bq. The extra port is visible only to machines only from all cluster nodes and not from outside. It is still behind any firewall that you might have Will it be always like that? Would it be possible in a future to have some cluster nodes outside of one's firewall? As soon as that happens a second port would have to be opened on a firewall consequently widening an attack vector. Again, it isn't about what current patch does or does not introduce. It is about an increment in number of gates from an attack can't be mounted. That's why I've referred to the 'surface' - it provides more chances for something to be forgotten, insufficiently tested, etc. > Improve Namenode robustness by prioritizing datanode heartbeats over client > requests > > > Key: HDFS-599 > URL: https://issues.apache.org/jira/browse/HDFS-599 > Project: Hadoop HDFS > Issue Type: Improvement > Components: name-node >Reporter: dhruba borthakur >Assignee: dhruba borthakur > > The namenode processes RPC requests from clients that are reading/writing to > files as well as heartbeats/block reports from datanodes. > Sometime, because of various reasons (Java GC runs, inconsistent performance > of NFS filer that stores HDFS transacttion logs, etc), the namenode > encounters transient slowness. For example, if the device that stores the > HDFS transaction logs becomes sluggish, the Namenode's ability to process > RPCs slows down to a certain extent. During this time, the RPCs from clients > as well as the RPCs from datanodes suffer in similar fashion. If the > underlying problem becomes worse, the NN's ability to process a heartbeat > from a DN is severly impacted, thus causing the NN to declare that the DN is > dead. Then the NN starts replicating blocks that used to reside on the > now-declared-dead datanode. This adds extra load to the NN. Then the > now-declared-datanode finally re-establishes contact with the NN, and sends a > block report. The block report processing on the NN is another heavyweight > activity, thus casing more load to the already overloaded namenode. > My proposal is tha the NN should try its best to continue processing RPCs > from datanodes and give lesser priority to serving client requests. The > Datanode RPCs are integral to the consistency and performance of the Hadoop > file system, and it is better to protect it at all costs. This will ensure > that NN recovers from the hiccup much faster than what it does now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-603) Most replica related classes cannot be accessed
[ https://issues.apache.org/jira/browse/HDFS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753205#action_12753205 ] Hairong Kuang commented on HDFS-603: +1. The patch looks good. Sorry for the confusion. I meat the two changes to ReplicasMap are NOT necessary. > Most replica related classes cannot be accessed > --- > > Key: HDFS-603 > URL: https://issues.apache.org/jira/browse/HDFS-603 > Project: Hadoop HDFS > Issue Type: Improvement > Components: data-node >Affects Versions: Append Branch >Reporter: Tsz Wo (Nicholas), SZE > Fix For: Append Branch > > Attachments: h603_20090908.patch, h603_20090909.patch > > > Currently, there are several replica related classes in > org.apache.hadoop.hdfs.server.datanode: > - ReplicaInfo > - ReplicaInPipelineInterface > - ReplicaInPipeline > - ReplicaUnderRecovery > - ReplicaWaitingToBeRecovered > - ReplicaBeingWritten > - FinalizedReplica > All these classes cannot be accessed above FSDatasetInterface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-550) DataNode restarts may introduce corrupt/duplicated/lost replicas when handling detached replicas
[ https://issues.apache.org/jira/browse/HDFS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753203#action_12753203 ] Hairong Kuang commented on HDFS-550: > This is harmless because they will get deleted in the next block report, > isn't it? No, this is not harmless. That's the key point. Block report does not handle duplicate replicas from one datanode. More problematic is that the temporary replicas under "detached" may be corrupt if DataNode dies when copy is in progress. So recovery introduces corrupt replicas. > DataNode restarts may introduce corrupt/duplicated/lost replicas when > handling detached replicas > > > Key: HDFS-550 > URL: https://issues.apache.org/jira/browse/HDFS-550 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: data-node >Affects Versions: 0.21.0 >Reporter: Hairong Kuang >Assignee: Hairong Kuang >Priority: Blocker > Fix For: Append Branch > > Attachments: detach.patch > > > Current trunk first calls detach to unlinks a finalized replica before > appending to this block. Unlink is done by temporally copying the block file > in the "current" subtree to a directory called "detach" under the volume's > daa directory and then copies it back when unlink succeeds. On datanode > restarts, datanodes recover faied unlink by copying replicas under "detach" > to "current". > There are two bugs with this implementation: > 1. The "detach" directory does not include in a snapshot. so rollback will > cause the "detaching" replicas to be lost. > 2. After a replica is copied to the "detach" directory, the information of > its original location is lost. The current implementation erroneously assumes > that the replica to be unlinked is under "current". This will make two > instances of replicas with the same block id to coexist in a datanode. Also > if a replica under "detach" is corrupt, the corrupt replica is moved to > "current" without being detected, polluting datanode data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-599) Improve Namenode robustness by prioritizing datanode heartbeats over client requests
[ https://issues.apache.org/jira/browse/HDFS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753204#action_12753204 ] dhruba borthakur commented on HDFS-599: --- > One issue I see with adding an extra port is that it increases the potential > attack surface and generally would be considered as less secure. Why would that be? The extra port is visible only to machines only from all cluster nodes and not from outside. It is still behind any firewall that you might have. Moreover, the default setting would still be to use one single port for DatanodeProtocol and ClientProtocol, so it should not affect (security) for preliminary users. Also, no new RPCs would be introduced by this patch, just splitting existing RPCs so that a few of them get served by one port while the other RPCs are served by another port. > Improve Namenode robustness by prioritizing datanode heartbeats over client > requests > > > Key: HDFS-599 > URL: https://issues.apache.org/jira/browse/HDFS-599 > Project: Hadoop HDFS > Issue Type: Improvement > Components: name-node >Reporter: dhruba borthakur >Assignee: dhruba borthakur > > The namenode processes RPC requests from clients that are reading/writing to > files as well as heartbeats/block reports from datanodes. > Sometime, because of various reasons (Java GC runs, inconsistent performance > of NFS filer that stores HDFS transacttion logs, etc), the namenode > encounters transient slowness. For example, if the device that stores the > HDFS transaction logs becomes sluggish, the Namenode's ability to process > RPCs slows down to a certain extent. During this time, the RPCs from clients > as well as the RPCs from datanodes suffer in similar fashion. If the > underlying problem becomes worse, the NN's ability to process a heartbeat > from a DN is severly impacted, thus causing the NN to declare that the DN is > dead. Then the NN starts replicating blocks that used to reside on the > now-declared-dead datanode. This adds extra load to the NN. Then the > now-declared-datanode finally re-establishes contact with the NN, and sends a > block report. The block report processing on the NN is another heavyweight > activity, thus casing more load to the already overloaded namenode. > My proposal is tha the NN should try its best to continue processing RPCs > from datanodes and give lesser priority to serving client requests. The > Datanode RPCs are integral to the consistency and performance of the Hadoop > file system, and it is better to protect it at all costs. This will ensure > that NN recovers from the hiccup much faster than what it does now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-606) ConcurrentModificationException in invalidateCorruptReplicas()
[
https://issues.apache.org/jira/browse/HDFS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Shvachko updated HDFS-606:
-
Status: Patch Available (was: Open)
Resubmitting because none of the three tests fail on my box. Trying to see
whether the failures from different Hudson runs will be consistent.
> ConcurrentModificationException in invalidateCorruptReplicas()
> --
>
> Key: HDFS-606
> URL: https://issues.apache.org/jira/browse/HDFS-606
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
>Affects Versions: 0.21.0
>Reporter: Konstantin Shvachko
>Assignee: Konstantin Shvachko
> Fix For: 0.21.0
>
> Attachments: CMEinCorruptReplicas.patch
>
>
> {{BlockManager.invalidateCorruptReplicas()}} iterates over
> DatanodeDescriptor-s while removing corrupt replicas from the descriptors.
> This causes {{ConcurrentModificationException}} if there is more than one
> replicas of the block. I ran into this exception debugging different
> scenarios in append, but it should be fixed in the trunk too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-606) ConcurrentModificationException in invalidateCorruptReplicas()
[
https://issues.apache.org/jira/browse/HDFS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Shvachko updated HDFS-606:
-
Status: Open (was: Patch Available)
> ConcurrentModificationException in invalidateCorruptReplicas()
> --
>
> Key: HDFS-606
> URL: https://issues.apache.org/jira/browse/HDFS-606
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
>Affects Versions: 0.21.0
>Reporter: Konstantin Shvachko
>Assignee: Konstantin Shvachko
> Fix For: 0.21.0
>
> Attachments: CMEinCorruptReplicas.patch
>
>
> {{BlockManager.invalidateCorruptReplicas()}} iterates over
> DatanodeDescriptor-s while removing corrupt replicas from the descriptors.
> This causes {{ConcurrentModificationException}} if there is more than one
> replicas of the block. I ran into this exception debugging different
> scenarios in append, but it should be fixed in the trunk too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-599) Improve Namenode robustness by prioritizing datanode heartbeats over client requests
[ https://issues.apache.org/jira/browse/HDFS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753194#action_12753194 ] Konstantin Boudnik commented on HDFS-599: - One issue I see with adding an extra port is that it increases the potential attack surface and generally would be considered as less secure. > Improve Namenode robustness by prioritizing datanode heartbeats over client > requests > > > Key: HDFS-599 > URL: https://issues.apache.org/jira/browse/HDFS-599 > Project: Hadoop HDFS > Issue Type: Improvement > Components: name-node >Reporter: dhruba borthakur >Assignee: dhruba borthakur > > The namenode processes RPC requests from clients that are reading/writing to > files as well as heartbeats/block reports from datanodes. > Sometime, because of various reasons (Java GC runs, inconsistent performance > of NFS filer that stores HDFS transacttion logs, etc), the namenode > encounters transient slowness. For example, if the device that stores the > HDFS transaction logs becomes sluggish, the Namenode's ability to process > RPCs slows down to a certain extent. During this time, the RPCs from clients > as well as the RPCs from datanodes suffer in similar fashion. If the > underlying problem becomes worse, the NN's ability to process a heartbeat > from a DN is severly impacted, thus causing the NN to declare that the DN is > dead. Then the NN starts replicating blocks that used to reside on the > now-declared-dead datanode. This adds extra load to the NN. Then the > now-declared-datanode finally re-establishes contact with the NN, and sends a > block report. The block report processing on the NN is another heavyweight > activity, thus casing more load to the already overloaded namenode. > My proposal is tha the NN should try its best to continue processing RPCs > from datanodes and give lesser priority to serving client requests. The > Datanode RPCs are integral to the consistency and performance of the Hadoop > file system, and it is better to protect it at all costs. This will ensure > that NN recovers from the hiccup much faster than what it does now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-603) Most replica related classes cannot be accessed
[ https://issues.apache.org/jira/browse/HDFS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HDFS-603: Attachment: h603_20090909.patch h603_20090909.patch: reverted the changes in ReplicasMap. Talked to Cos: he was actually talking about the new method in ReplicasMap. So it is not a problem now. > Most replica related classes cannot be accessed > --- > > Key: HDFS-603 > URL: https://issues.apache.org/jira/browse/HDFS-603 > Project: Hadoop HDFS > Issue Type: Improvement > Components: data-node >Affects Versions: Append Branch >Reporter: Tsz Wo (Nicholas), SZE > Fix For: Append Branch > > Attachments: h603_20090908.patch, h603_20090909.patch > > > Currently, there are several replica related classes in > org.apache.hadoop.hdfs.server.datanode: > - ReplicaInfo > - ReplicaInPipelineInterface > - ReplicaInPipeline > - ReplicaUnderRecovery > - ReplicaWaitingToBeRecovered > - ReplicaBeingWritten > - FinalizedReplica > All these classes cannot be accessed above FSDatasetInterface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-603) Most replica related classes cannot be accessed
[ https://issues.apache.org/jira/browse/HDFS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753182#action_12753182 ] Tsz Wo (Nicholas), SZE commented on HDFS-603: - > Tthe two changes to ReplicasMap are necessary. For the newly introduced > method get(Replica r), the returned reference should be the same as the input > reference. Yes, I will revert the changes. > I will a sort of uneasiness when an input ref. is being simply return from a > wrapper method. It opens all sorts of possible security issues. Shall the > parameter, at very least, be declared as final? Could you be more specific? Which methods you are talking about? What are the security issues? Which parameters should be declared as final? > Most replica related classes cannot be accessed > --- > > Key: HDFS-603 > URL: https://issues.apache.org/jira/browse/HDFS-603 > Project: Hadoop HDFS > Issue Type: Improvement > Components: data-node >Affects Versions: Append Branch >Reporter: Tsz Wo (Nicholas), SZE > Fix For: Append Branch > > Attachments: h603_20090908.patch > > > Currently, there are several replica related classes in > org.apache.hadoop.hdfs.server.datanode: > - ReplicaInfo > - ReplicaInPipelineInterface > - ReplicaInPipeline > - ReplicaUnderRecovery > - ReplicaWaitingToBeRecovered > - ReplicaBeingWritten > - FinalizedReplica > All these classes cannot be accessed above FSDatasetInterface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-603) Most replica related classes cannot be accessed
[ https://issues.apache.org/jira/browse/HDFS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753177#action_12753177 ] Konstantin Boudnik commented on HDFS-603: - I will a sort of uneasiness when an input ref. is being simply return from a wrapper method. It opens all sorts of possible security issues. Shall the parameter, at very least, be declared as final? > Most replica related classes cannot be accessed > --- > > Key: HDFS-603 > URL: https://issues.apache.org/jira/browse/HDFS-603 > Project: Hadoop HDFS > Issue Type: Improvement > Components: data-node >Affects Versions: Append Branch >Reporter: Tsz Wo (Nicholas), SZE > Fix For: Append Branch > > Attachments: h603_20090908.patch > > > Currently, there are several replica related classes in > org.apache.hadoop.hdfs.server.datanode: > - ReplicaInfo > - ReplicaInPipelineInterface > - ReplicaInPipeline > - ReplicaUnderRecovery > - ReplicaWaitingToBeRecovered > - ReplicaBeingWritten > - FinalizedReplica > All these classes cannot be accessed above FSDatasetInterface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-602) Atempt to make a directory under an existing file on DistributedFileSystem should throw an FileAlreadyExistsException instead of FileNotFoundException
[ https://issues.apache.org/jira/browse/HDFS-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753171#action_12753171 ] Jitendra Nath Pandey commented on HDFS-602: --- +1 look good. > Atempt to make a directory under an existing file on DistributedFileSystem > should throw an FileAlreadyExistsException instead of FileNotFoundException > -- > > Key: HDFS-602 > URL: https://issues.apache.org/jira/browse/HDFS-602 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Boris Shkolnik >Assignee: Boris Shkolnik > Attachments: HDFS-602.patch > > > Atempt to make a directory under an existing file on DistributedFileSystem > should throw an FileAlreadyExistsException instead of FileNotFoundException. > Also we should unwrap this exception from RemoteException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-602) Atempt to make a directory under an existing file on DistributedFileSystem should throw an FileAlreadyExistsException instead of FileNotFoundException
[ https://issues.apache.org/jira/browse/HDFS-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753170#action_12753170 ] Boris Shkolnik commented on HDFS-602: - No test included because it is covered by FileSystemContractBaseTest.testMkdirsFailsForSubdirectoryOfExistingFile() > Atempt to make a directory under an existing file on DistributedFileSystem > should throw an FileAlreadyExistsException instead of FileNotFoundException > -- > > Key: HDFS-602 > URL: https://issues.apache.org/jira/browse/HDFS-602 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Boris Shkolnik >Assignee: Boris Shkolnik > Attachments: HDFS-602.patch > > > Atempt to make a directory under an existing file on DistributedFileSystem > should throw an FileAlreadyExistsException instead of FileNotFoundException. > Also we should unwrap this exception from RemoteException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-550) DataNode restarts may introduce corrupt/duplicated/lost replicas when handling detached replicas
[ https://issues.apache.org/jira/browse/HDFS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753134#action_12753134 ] dhruba borthakur commented on HDFS-550: --- > So the recovery adds duplicate replicas of the same block id to a datanode > disk ... (A) This is true. This is harmless because they will get deleted in the next block report, isn't it? > at least DataNode should treat the detached directory as a tmp directory and > removes its content at Startup time.. (B) I completely agree. The reason this is being done is because the FileUtil.renameFile() is not atomic on Windows. Hence it is better to have issue A (as marked above) rather than losing blocks on Windows platform. > My unit tests test only the new recovery works or not. I am fine with the code restructuring that you have done. +1. However, if this is supposed to fix a bug in the current code, isn't it a good idea to first write a unit test to trigger that problem and then demonstrate that the unit test works well with the code in the patch. > DataNode restarts may introduce corrupt/duplicated/lost replicas when > handling detached replicas > > > Key: HDFS-550 > URL: https://issues.apache.org/jira/browse/HDFS-550 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: data-node >Affects Versions: 0.21.0 >Reporter: Hairong Kuang >Assignee: Hairong Kuang >Priority: Blocker > Fix For: Append Branch > > Attachments: detach.patch > > > Current trunk first calls detach to unlinks a finalized replica before > appending to this block. Unlink is done by temporally copying the block file > in the "current" subtree to a directory called "detach" under the volume's > daa directory and then copies it back when unlink succeeds. On datanode > restarts, datanodes recover faied unlink by copying replicas under "detach" > to "current". > There are two bugs with this implementation: > 1. The "detach" directory does not include in a snapshot. so rollback will > cause the "detaching" replicas to be lost. > 2. After a replica is copied to the "detach" directory, the information of > its original location is lost. The current implementation erroneously assumes > that the replica to be unlinked is under "current". This will make two > instances of replicas with the same block id to coexist in a datanode. Also > if a replica under "detach" is corrupt, the corrupt replica is moved to > "current" without being detected, polluting datanode data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
