Linux NILFS development
 help / color / mirror / Atom feed
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

  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