From: dexen deVries <dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Vyacheslav Dubeyko <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>
Subject: Re: read error on superblock
Date: Tue, 24 Jul 2012 09:52:18 +0200 [thread overview]
Message-ID: <31237317.NQxpWWcrpc@coil> (raw)
In-Reply-To: <1343111197.1982.32.camel@slavad-ubuntu-11>
Hi Vyacheslav,
On Tuesday 24 of July 2012 10:26:37 you wrote:
> I am afraid that it is not so good from the end user point of view.
>
> First of all, the message "mount: /dev/sda3: can't read superblock" can
> confuse user. The reason is bad sectors inside the volume but user is
> informed about impossibility to read superblock.
>
> Secondly, it is possible situation when it really needs to use a volume
> in the case of presence of bad sectors. And I think that users can
> expect such NILFS behavior because of declared reliability.
>
> Unfortunately, as I can understand, NILFS hasn't bad blocks table and
> can't process situation of bad blocks presence on volume correctly. It
> means that NILFS interprets bad blocks as exceptional case. But from my
> point of view, it makes sense to interpret bad blocks as usual thing and
> try to work in the presence of ones. For example, fsck potentially can
> check NILFS volume on bad blocks presence, construct bad blocks table
> and save it on the volume.
>
> I suggest to add "virtual" special file for bad blocks description. It
> can be described by inode in ifile and all bad blocks can be described
> in DAT file as parts of this "virtual" special file. So, as a result,
> NILFS file system driver will have bad blocks table which can be a basis
> for excluding bad blocks from operation and trying to survive in the not
> good device environment.
>
> What do you think about such idea?
I believe bad sectors to be thing of the past mostly; any decent harddrive
(probably also any decent SSD) should re-map them after some re-reads. Some
data & meta-data loss is possible, but overall the FS should be accessible
again.
I have no idea why my particular HDD did not re-map; perhaps it just takes
much longer than I gave it.
As a point of reference, XFS does not do bad block management either; however,
the partition driver of IRIX does bad sector management -- so it is
implemented one layer below the FS.
I guess it /may be/ possible to use Linux' `dm' driver in such manner.
Cheers,
--
dexen deVries
[[[↓][→]]]
"all dichotomies are either true or false" is a true paradox because it's
paradoxical only if it is a paradox ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-07-24 7:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-23 8:45 read error on superblock dexen deVries
2012-07-23 9:17 ` Vyacheslav Dubeyko
2012-07-23 9:24 ` dexen deVries
2012-07-23 9:37 ` Vyacheslav Dubeyko
2012-07-23 9:39 ` Ryusuke Konishi
[not found] ` <20120723.183907.154986664.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2012-07-23 9:42 ` dexen deVries
2012-07-23 11:06 ` dexen deVries
2012-07-23 11:19 ` Ryusuke Konishi
[not found] ` <20120723.201918.94868195.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2012-07-23 18:24 ` dexen deVries
2012-07-24 0:06 ` Ryusuke Konishi
[not found] ` <20120724.090604.40913934.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2012-07-24 6:26 ` Vyacheslav Dubeyko
2012-07-24 7:52 ` dexen deVries [this message]
2012-07-24 16:46 ` Ryusuke Konishi
[not found] ` <20120725.014653.38326039.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2012-07-24 20:05 ` Nick Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=31237317.NQxpWWcrpc@coil \
--to=dexen.devries-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox