All of lore.kernel.org
 help / color / mirror / Atom feed
From: mindentropy@gmail.com (mindentropy)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Blocking the access to the device files.
Date: Thu, 30 Dec 2010 00:24:12 +0530	[thread overview]
Message-ID: <201012300024.12230.mindentropy@gmail.com> (raw)
In-Reply-To: <AANLkTik1-wa=oa29Dv_Eh8iOzmau02ih-Vr_ObhTbK+N@mail.gmail.com>

On Wednesday 29 Dec 2010 10:31:37 pm Greg Freemyer wrote:
> On Wed, Dec 29, 2010 at 11:12 AM, Mulyadi Santosa
> 
> <mulyadi.santosa@gmail.com> wrote:
> > On Wed, Dec 29, 2010 at 20:06, Prasad Joshi <prasadjoshi124@gmail.com> 
wrote:
> >> Hello All,
> >> 
> >> ZFS file system has a property called devices. If turned off, ZFS
> >> would not allow access to the device files (block/character) present
> >> on the file system. I want to implement the same behavior on the a
> >> Linux File System.
> > 
> > I don't know about ZFS, so could you please elaborate on what you mean
> > by "ZFS could disallow access"?
> > 
> > IMHO, (untested), you could simply do it using usual Linux
> > file/directory permission up to SELinux/AppArmor....so, is that what
> > you mean?
> > 
> > --
> > regards,
> > 
> > Mulyadi Santosa
> 
> Mulyadi,
> 
> My guess is that it is more complex than that.
> 
> Some filesystems have issues if the raw drive is read while the
> filesystem is mounted.  I think it is caused by inconsistencies in the
> various cache's.  ie. iirc, At least in the 2.4 kernel there was not a
> single unified cache for block layer and filesystems.  So doing raw
> reads of underlying device while it was mounted could cause the caches
> to get out of sync.
> 
> I don't recall the details, but either the kernel would oops or the
> filesystem would become corrupt.  I don't know if any 2.6 filesystems
> still have that issue.  Anyway ZFS must have a similar issue.
> 
> So a ZFS filesystem developer knowing this was a conflict could add a
> check in the /dev/sda open() that would fail the open if there was a
> mounted filesystem of type ZFS on the drive.
> 
> And the mount should fail if /dev/sda is already open.
> 
> I'm not aware of the 2.6.x linux kernel offering any infrastructure to
> help with that issue.
> 
> Greg
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Greg,
> So doing raw
> reads of underlying device while it was mounted could cause the caches
> to get out of sync.

    So doing a 'dd' would cause the kernel to oops?

Thanks.

  parent reply	other threads:[~2010-12-29 18:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-29 13:06 Blocking the access to the device files Prasad Joshi
2010-12-29 16:12 ` Mulyadi Santosa
2010-12-29 17:01   ` Greg Freemyer
2010-12-29 18:06     ` Mulyadi Santosa
2010-12-29 18:54     ` mindentropy [this message]
2010-12-29 19:00       ` Mulyadi Santosa
2010-12-29 19:02       ` Greg Freemyer
2010-12-29 19:07         ` Mulyadi Santosa
2010-12-29 19:09           ` Greg Freemyer
2010-12-29 23:32   ` Prasad Joshi
2010-12-30  0:07     ` Greg Freemyer
2010-12-30  0:24     ` Henry Gebhardt
2010-12-30  7:10       ` Rajat Sharma

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=201012300024.12230.mindentropy@gmail.com \
    --to=mindentropy@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.