[
https://issues.apache.org/jira/browse/HDFS-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842027#comment-13842027
]
Arpit Agarwal commented on HDFS-2832:
-------------------------------------
{quote}
Is there any additional overhead from splitting?
{quote}
DNs are not splitting block reports right now and there is no extra overhead in
NN to handle it.
{quote}
Have you looked at the additional memory overhead on the NN and DN from
splitting up storages? With 10 disks on a DN, this could mean effectively 10x
the number of DNs as before. I think this is still insignificant, but you all
know better than me.
{quote}
Yes, the bulk of the space is consumed by the block information, the volumes
themselves are insignificant.
{quote}
I'd like to see more description of the client API, namely the file attribute
APIs. I'll also note that LocatedBlock is not a public API; you can hack around
by downcasting BlockLocation to HdfsBlockLocation to fish out the LocatedBlock,
but ultimately we probably want to expose StorageType in BlockLocation itself.
API examples would be great, from both the command line and the programmatic
API.
I think this earlier question/answer didn't make it into the doc: what happens
when this file is distcp'd or copied? Arpit's earlier answer of clearing this
field makes sense (or maybe we need a cp -a command).
{quote}
As mentioned earlier we'll document these in more detail once we start work on
them i.e. post phase-1 merge.
{quote}
I'd like to see more discussion in the doc of migrating blocks that are
currently open for short-circuit read. SCR is very common
{quote}
It's in the doc. The operating system, be it Unix or Windows will not let you
remove a file as long as any process has a handle open to it. Even if the file
looks deleted, it will remain on disk at least until the last open handle goes
away. Quota permitting, the application can create additional replicas on
alternate storage media while it keeps the existing handle open.
{quote}
Is this going to work with rolling upgrades?
{quote}
HDFS does not support rolling upgrades today.
{quote}
Storage is not always truly hierarchical, it depends on your provisioning. The
current strategy of always falling back from SSD to HDD is more ambiguous when
you have more than two storage types, especially with something like a tape or
NAS tier. Maybe this should be configurable somehow.
One of the mentioned potential uses is to do automatic migration between
storage types based on usage patterns. In this kind of scenario, it's necessary
to support more expressive forms of resource management, e.g. YARN's fair
scheduler. Quotas by themselves aren't sufficient.
{quote}
We have tried to avoid the term 'hierarchical' because we are not adding any
awareness of storage hierarchy. HDD is just the most sensible default although
as we mention in the future section we can look into adding support for tapes
etc. Automatic migration is mentioned for completeness but we are not thinking
about the design for it now. Anyone from the community is free to post ideas
however.
Andrew, the design is the same you reviewed in August and we have discussed
some of these earlier so I encourage you to read through the comment history.
> Enable support for heterogeneous storages in HDFS
> -------------------------------------------------
>
> Key: HDFS-2832
> URL: https://issues.apache.org/jira/browse/HDFS-2832
> Project: Hadoop HDFS
> Issue Type: New Feature
> Affects Versions: 0.24.0
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Attachments: 20130813-HeterogeneousStorage.pdf,
> 20131125-HeterogeneousStorage-TestPlan.pdf,
> 20131125-HeterogeneousStorage.pdf,
> 20131202-HeterogeneousStorage-TestPlan.pdf,
> 20131203-HeterogeneousStorage-TestPlan.pdf, H2832_20131107.patch,
> editsStored, h2832_20131023.patch, h2832_20131023b.patch,
> h2832_20131025.patch, h2832_20131028.patch, h2832_20131028b.patch,
> h2832_20131029.patch, h2832_20131103.patch, h2832_20131104.patch,
> h2832_20131105.patch, h2832_20131107b.patch, h2832_20131108.patch,
> h2832_20131110.patch, h2832_20131110b.patch, h2832_20131111.patch,
> h2832_20131112.patch, h2832_20131112b.patch, h2832_20131114.patch,
> h2832_20131118.patch, h2832_20131119.patch, h2832_20131119b.patch,
> h2832_20131121.patch, h2832_20131122.patch, h2832_20131122b.patch,
> h2832_20131123.patch, h2832_20131124.patch, h2832_20131202.patch,
> h2832_20131203.patch
>
>
> HDFS currently supports configuration where storages are a list of
> directories. Typically each of these directories correspond to a volume with
> its own file system. All these directories are homogeneous and therefore
> identified as a single storage at the namenode. I propose, change to the
> current model where Datanode * is a * storage, to Datanode * is a collection
> * of strorages.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
