Hi,
On Fri, May 11, 2001 at 04:54:44PM +0200, Daniel Phillips wrote:
> The only reasonable way I can think of getting a block-coherent view
> underneath a mounted fs is to have a reverse map, and update it each
> time we map block into the page cache or unmap it.
It's called the "buffer
Hi,
On Fri, May 11, 2001 at 04:54:44PM +0200, Daniel Phillips wrote:
The only reasonable way I can think of getting a block-coherent view
underneath a mounted fs is to have a reverse map, and update it each
time we map block into the page cache or unmap it.
It's called the buffer cache,
On Mon, 7 May 2001, Pavel Machek wrote:
> OTOH with current way if you make mistake in kernel, fsck will not
> automatically inherit it; therefore fsck is likely to work even if
> kernel ext2 is b0rken [and that's fairly important]
... and by the same logics you should make fsck implement its
On Monday 07 May 2001 20:42, Pavel Machek wrote:
> > > It's not exactly "kernel-based fsck". What I've been talking
> > > about is secondary filesystem providing coherent access to
> > > primary fs metadata. I.e. mount -t ext2meta -o master=/usr none
> > > /mnt and then access through
gHi!
> > It's not exactly "kernel-based fsck". What I've been talking about
> > is secondary filesystem providing coherent access to primary fs
> > metadata. I.e. mount -t ext2meta -o master=/usr none /mnt and
> > then access through /mnt/super, /mnt/block_bitmap, etc.
> >
> >
gHi!
It's not exactly kernel-based fsck. What I've been talking about
is secondary filesystem providing coherent access to primary fs
metadata. I.e. mount -t ext2meta -o master=/usr none /mnt and
then access through /mnt/super, /mnt/block_bitmap, etc.
Call me stupid
On Monday 07 May 2001 20:42, Pavel Machek wrote:
It's not exactly kernel-based fsck. What I've been talking
about is secondary filesystem providing coherent access to
primary fs metadata. I.e. mount -t ext2meta -o master=/usr none
/mnt and then access through /mnt/super,
On Mon, 7 May 2001, Pavel Machek wrote:
OTOH with current way if you make mistake in kernel, fsck will not
automatically inherit it; therefore fsck is likely to work even if
kernel ext2 is b0rken [and that's fairly important]
... and by the same logics you should make fsck implement its own
[EMAIL PROTECTED] wrote:
>
> I have tried this approach too a couple of years ago. I came to the idea
> that I want some kind of "event reporting" mechanism to know when
> application faults and when other events (like I/O) occurs. Booting is
> just the tip of the iceberg. MOST big apps are
[EMAIL PROTECTED] wrote:
I have tried this approach too a couple of years ago. I came to the idea
that I want some kind of event reporting mechanism to know when
application faults and when other events (like I/O) occurs. Booting is
just the tip of the iceberg. MOST big apps are seeking on
I have tried this approach too a couple of years ago. I came to the idea
that I want some kind of "event reporting" mechanism to know when
application faults and when other events (like I/O) occurs. Booting is
just the tip of the iceberg. MOST big apps are seeking on startup because
a) their
I have tried this approach too a couple of years ago. I came to the idea
that I want some kind of event reporting mechanism to know when
application faults and when other events (like I/O) occurs. Booting is
just the tip of the iceberg. MOST big apps are seeking on startup because
a) their
Alan writes:
> > Actually, the EVMS project does exactly this. All I/O is done on a full
> > disk basis, and essentially does block remapping for each partition. This
> > also solves the problem of cache inconsistency if accessing the parent
> > device vs. accessing the partition.
>
>
> Actually, the EVMS project does exactly this. All I/O is done on a full
> disk basis, and essentially does block remapping for each partition. This
> also solves the problem of cache inconsistency if accessing the parent
> device vs. accessing the partition.
Interesting. Can EVMS handle the
Alan writes:
> > an interesting task when your root lives on /dev/sda1. Ditto for destroying
> > a single partition (not mounted/used by swap/etc.) while you have some
> > other partition in use. IWBNI we had a decent API for handling partition
> > tables...
>
> Partitions are just very crude
> an interesting task when your root lives on /dev/sda1. Ditto for destroying
> a single partition (not mounted/used by swap/etc.) while you have some
> other partition in use. IWBNI we had a decent API for handling partition
> tables...
Partitions are just very crude logical volumes, and
an interesting task when your root lives on /dev/sda1. Ditto for destroying
a single partition (not mounted/used by swap/etc.) while you have some
other partition in use. IWBNI we had a decent API for handling partition
tables...
Partitions are just very crude logical volumes, and
Alan writes:
an interesting task when your root lives on /dev/sda1. Ditto for destroying
a single partition (not mounted/used by swap/etc.) while you have some
other partition in use. IWBNI we had a decent API for handling partition
tables...
Partitions are just very crude logical
Actually, the EVMS project does exactly this. All I/O is done on a full
disk basis, and essentially does block remapping for each partition. This
also solves the problem of cache inconsistency if accessing the parent
device vs. accessing the partition.
Interesting. Can EVMS handle the
Alan writes:
Actually, the EVMS project does exactly this. All I/O is done on a full
disk basis, and essentially does block remapping for each partition. This
also solves the problem of cache inconsistency if accessing the parent
device vs. accessing the partition.
Interesting. Can
On Sun, 6 May 2001, Chris Wedgwood wrote:
> It's not exactly "kernel-based fsck". What I've been talking about
> is secondary filesystem providing coherent access to primary fs
> metadata. I.e. mount -t ext2meta -o master=/usr none /mnt and
> then access through /mnt/super,
On Sun, May 06, 2001 at 03:00:58PM +1200, Chris Wedgwood wrote:
> On Sun, May 06, 2001 at 04:50:01AM +0200, Andrea Arcangeli wrote:
>
> Moving e2fsck into the kernel is a completly different matter
> than caching the blockdevice accesses with pagecache instead of
> buffercache.
>
>
Chris Wedgewood writes:
> As I said, I'm not takling about kernel based fsck, although for
> _VERY_ large filesystems even with journalling I suspect it will be
> required one day (so it can run in the background and do consistency
> checking when the machine is idle).
Actually, I was talking
On Sun, 6 May 2001, Chris Wedgwood wrote:
> On Sun, May 06, 2001 at 04:50:01AM +0200, Andrea Arcangeli wrote:
> About a kernel based fsck Alexander told me he likes it, I
> personally don't care about it that much because I believe...
>
> As I said, I'm not takling about kernel
On Sun, May 06, 2001 at 02:14:37PM +1200, Chris Wedgwood wrote:
> You don't need block device for fsck, in fact some OS require you use
> character devices (e.g. Solaris).
Moving e2fsck into the kernel is a completly different matter than
caching the blockdevice accesses with pagecache instead
On Sat, May 05, 2001 at 03:18:08PM +1200, Chris Wedgwood wrote:
> On Fri, May 04, 2001 at 05:29:40PM +0200, Andrea Arcangeli wrote:
>
> once block_dev is in pagecache there will obviously be no-way to
> share cache between the block device and the filesystem, because
> all the caches
Rogier Wolff writes:
> Richard Gooch wrote:
> >
> > - next boot, init(8) checks the file, and if it exists, opens the root
> > FS block device and reads in each block listed in the file. The
> > effect is to warm the buffer cache extremely quickly. The head will
> > move in one direction,
On Sat, 5 May 2001, Albert D. Cahalan wrote:
> case P_SWAP:
> sprintf(tmp, "%4.4s ",
> scale_k(((task->size - task->resident) << CL_pg_shift), 4, 1));
> break;
Albert, you can't be serious. The system had demand-loading for almost
ten years. ->size - ->resident can be huge
Richard Gooch wrote:
>
> - next boot, init(8) checks the file, and if it exists, opens the root
> FS block device and reads in each block listed in the file. The
> effect is to warm the buffer cache extremely quickly. The head will
> move in one direction, grabbing data as it flys by. I
Alexander Viro writes:
>> On Fri, 4 May 2001, Alexander Viro wrote:
>>> Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
> ^^^
Ah, you learn from the master.
> ObProcfs: I don't think that walking the
Alexander Viro writes:
On Fri, 4 May 2001, Alexander Viro wrote:
Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
^^^
Ah, you learn from the master.
ObProcfs: I don't think that walking the page
Richard Gooch wrote:
- next boot, init(8) checks the file, and if it exists, opens the root
FS block device and reads in each block listed in the file. The
effect is to warm the buffer cache extremely quickly. The head will
move in one direction, grabbing data as it flys by. I expect
On Sat, 5 May 2001, Albert D. Cahalan wrote:
case P_SWAP:
sprintf(tmp, %4.4s ,
scale_k(((task-size - task-resident) CL_pg_shift), 4, 1));
break;
Albert, you can't be serious. The system had demand-loading for almost
ten years. -size - -resident can be huge with no swap at
On Sat, May 05, 2001 at 03:18:08PM +1200, Chris Wedgwood wrote:
On Fri, May 04, 2001 at 05:29:40PM +0200, Andrea Arcangeli wrote:
once block_dev is in pagecache there will obviously be no-way to
share cache between the block device and the filesystem, because
all the caches will
On Sun, May 06, 2001 at 02:14:37PM +1200, Chris Wedgwood wrote:
You don't need block device for fsck, in fact some OS require you use
character devices (e.g. Solaris).
Moving e2fsck into the kernel is a completly different matter than
caching the blockdevice accesses with pagecache instead of
On Sun, 6 May 2001, Chris Wedgwood wrote:
On Sun, May 06, 2001 at 04:50:01AM +0200, Andrea Arcangeli wrote:
About a kernel based fsck Alexander told me he likes it, I
personally don't care about it that much because I believe...
As I said, I'm not takling about kernel based
Chris Wedgewood writes:
As I said, I'm not takling about kernel based fsck, although for
_VERY_ large filesystems even with journalling I suspect it will be
required one day (so it can run in the background and do consistency
checking when the machine is idle).
Actually, I was talking with
On Sun, May 06, 2001 at 03:00:58PM +1200, Chris Wedgwood wrote:
On Sun, May 06, 2001 at 04:50:01AM +0200, Andrea Arcangeli wrote:
Moving e2fsck into the kernel is a completly different matter
than caching the blockdevice accesses with pagecache instead of
buffercache.
No, I
On Sun, 6 May 2001, Chris Wedgwood wrote:
It's not exactly kernel-based fsck. What I've been talking about
is secondary filesystem providing coherent access to primary fs
metadata. I.e. mount -t ext2meta -o master=/usr none /mnt and
then access through /mnt/super,
On Fri, 4 May 2001, Alan Cox wrote:
>
> iso9660 alas doesn't allow you to do that. You can speed it up by reading
> the entire file into memory rather than paging it in (or reading it in and
> then executing it). iso9660 layout is pretty constrained and designed for
> linear file reads
Note
> Now, if you want to speed up accesses, there are things you can do. You
> can lay out the filesystem in the access order - trace the IO accesses at
> bootup ("which file, which offset, which metadata block?") and lay out the
> blocks of the files in exactly the right order. Then you will get
Alexander Viro writes:
>
>
> On Fri, 4 May 2001, Richard Gooch wrote:
>
> > I don't bother splitting /usr off /. I gave up doing that when disc
> > became cheap. There's no point anymore. And since I have a lightweight
>
> Yes, there is. Locality. Resistance to fs fuckups. Resistance to
>
On Fri, 4 May 2001, Richard Gooch wrote:
> I don't bother splitting /usr off /. I gave up doing that when disc
> became cheap. There's no point anymore. And since I have a lightweight
Yes, there is. Locality. Resistance to fs fuckups. Resistance to disk
fuckups. Easier to restore from tape.
Alexander Viro writes:
>
>
> On Fri, 4 May 2001, Richard Gooch wrote:
>
> > > Two of them: use less bloated shell (and link it statically) and
> > > clean your rc scripts.
> >
> > No, because I'm not using the latest bloated version of bash, and I'm
>
> Umm... Last version of bash I could
On Fri, 4 May 2001, Richard Gooch wrote:
> > Two of them: use less bloated shell (and link it statically) and
> > clean your rc scripts.
>
> No, because I'm not using the latest bloated version of bash, and I'm
Umm... Last version of bash I could call not bloated was _long_ time
ago.
On Fri, 4 May 2001, Alexander Viro wrote:
>
> ObProcfs: I don't think that walking the page tables is a good way to
> compute RSS, especially since VM maintains the thing.
Well, the VM didn't always use to maintain the stuff it does now, so I bet
that most of the code is just old code that
On Fri, May 04 2001, Richard Gooch wrote:
> The idea I had (motivated by the desire to eliminate random disc
> seeks, which is the limiting factor in how fast my boxes boot) was:
>
> - init(8) issues an ioctl(2) on the root FS block device which turns
> on recording of block reads (it records
Alexander Viro writes:
>
>
> On Fri, 4 May 2001, Richard Gooch wrote:
>
> > However, doing an ioctl(2) on the block device won't help. So the
> > question is, where to add the hook? One possibility is the FS, and
> > record inum,bnum pairs. But of course we don't have a way of accessing
> >
On Fri, 4 May 2001, Richard Gooch wrote:
> However, doing an ioctl(2) on the block device won't help. So the
> question is, where to add the hook? One possibility is the FS, and
> record inum,bnum pairs. But of course we don't have a way of accessing
> via inum in user-space. So that's no
On Fri, 4 May 2001, Linus Torvalds wrote:
>
> On Fri, 4 May 2001, Alexander Viro wrote:
> >
> > Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
^^^
> > * add pagecache access for block device
>
Linus Torvalds writes:
> Now, if you want to speed up accesses, there are things you can
> do. You can lay out the filesystem in the access order - trace the
> IO accesses at bootup ("which file, which offset, which metadata
> block?") and lay out the blocks of the files in exactly the right
>
On Fri, 4 May 2001, Alexander Viro wrote:
>
> Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
> * add pagecache access for block device
> * put your "real" root on /dev/loop0 (setup from initrd)
> * dd
You're one sick puppy.
Now, the above is
On Fri, 4 May 2001, Linus Torvalds wrote:
> Now, if you want to speed up accesses, there are things you can do. You
> can lay out the filesystem in the access order - trace the IO accesses at
> bootup ("which file, which offset, which metadata block?") and lay out the
> blocks of the files in
On Fri, 4 May 2001, Andrea Arcangeli wrote:
> On Fri, May 04, 2001 at 01:56:14PM +0200, Jens Axboe wrote:
> > Or you can rewrite block_read/write to use the page cache, in which case
> > you'd have more luck doing the above.
>
> once block_dev is in pagecache there will obviously be no-way to
On Fri, 4 May 2001, Rogier Wolff wrote:
>
> Linus Torvalds wrote:
> >
> > Ehh. Doing that would be extremely stupid, and would slow down your boot
> > and nothing more.
>
> Ehhh, Linus, Linearly reading my harddisk goes at 26Mb per second.
You obviously didn't read my explanation of _why_ it
On Fri, May 04, 2001 at 01:56:14PM +0200, Jens Axboe wrote:
> Or you can rewrite block_read/write to use the page cache, in which case
> you'd have more luck doing the above.
once block_dev is in pagecache there will obviously be no-way to share
cache between the block device and the filesystem,
Rogier Wolff <[EMAIL PROTECTED]> wrote:
> during boot. I can then reshuffle my disk to have that 50M of data at
> the beginning and reading all that into 50M of cache, I can save
Wasn't that one of the goals of the LVM project, along snapshots and
block-level HSM ?
-
To unsubscribe from this
On Fri, May 04 2001, Rogier Wolff wrote:
> > On Thu, 3 May 2001, Alan Cox wrote:
> > > Ditto for some CD based stuff. You burn the important binaries to the front
> > > of the CD, then at boot dd 64Mb to /dev/null to prime the libraries and
> > > avoid a lot of seeking during boot up from the
Linus Torvalds wrote:
>
> On Thu, 3 May 2001, Alan Cox wrote:
> > Ditto for some CD based stuff. You burn the important binaries to the front
> > of the CD, then at boot dd 64Mb to /dev/null to prime the libraries and
> > avoid a lot of seeking during boot up from the CD-ROM.
> >
> > However I
Linus Torvalds wrote:
On Thu, 3 May 2001, Alan Cox wrote:
Ditto for some CD based stuff. You burn the important binaries to the front
of the CD, then at boot dd 64Mb to /dev/null to prime the libraries and
avoid a lot of seeking during boot up from the CD-ROM.
However I could do
On Fri, May 04 2001, Rogier Wolff wrote:
On Thu, 3 May 2001, Alan Cox wrote:
Ditto for some CD based stuff. You burn the important binaries to the front
of the CD, then at boot dd 64Mb to /dev/null to prime the libraries and
avoid a lot of seeking during boot up from the CD-ROM.
Rogier Wolff [EMAIL PROTECTED] wrote:
during boot. I can then reshuffle my disk to have that 50M of data at
the beginning and reading all that into 50M of cache, I can save
Wasn't that one of the goals of the LVM project, along snapshots and
block-level HSM ?
-
To unsubscribe from this list:
On Fri, May 04, 2001 at 01:56:14PM +0200, Jens Axboe wrote:
Or you can rewrite block_read/write to use the page cache, in which case
you'd have more luck doing the above.
once block_dev is in pagecache there will obviously be no-way to share
cache between the block device and the filesystem,
On Fri, 4 May 2001, Rogier Wolff wrote:
Linus Torvalds wrote:
Ehh. Doing that would be extremely stupid, and would slow down your boot
and nothing more.
Ehhh, Linus, Linearly reading my harddisk goes at 26Mb per second.
You obviously didn't read my explanation of _why_ it is stupid.
On Fri, 4 May 2001, Andrea Arcangeli wrote:
On Fri, May 04, 2001 at 01:56:14PM +0200, Jens Axboe wrote:
Or you can rewrite block_read/write to use the page cache, in which case
you'd have more luck doing the above.
once block_dev is in pagecache there will obviously be no-way to share
On Fri, 4 May 2001, Linus Torvalds wrote:
Now, if you want to speed up accesses, there are things you can do. You
can lay out the filesystem in the access order - trace the IO accesses at
bootup (which file, which offset, which metadata block?) and lay out the
blocks of the files in
On Fri, 4 May 2001, Alexander Viro wrote:
Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
* add pagecache access for block device
* put your real root on /dev/loop0 (setup from initrd)
* dd
You're one sick puppy.
Now, the above is basically
Linus Torvalds writes:
Now, if you want to speed up accesses, there are things you can
do. You can lay out the filesystem in the access order - trace the
IO accesses at bootup (which file, which offset, which metadata
block?) and lay out the blocks of the files in exactly the right
order.
On Fri, 4 May 2001, Linus Torvalds wrote:
On Fri, 4 May 2001, Alexander Viro wrote:
Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
^^^
* add pagecache access for block device
*
Alexander Viro writes:
On Fri, 4 May 2001, Richard Gooch wrote:
However, doing an ioctl(2) on the block device won't help. So the
question is, where to add the hook? One possibility is the FS, and
record inum,bnum pairs. But of course we don't have a way of accessing
via inum in
On Fri, May 04 2001, Richard Gooch wrote:
The idea I had (motivated by the desire to eliminate random disc
seeks, which is the limiting factor in how fast my boxes boot) was:
- init(8) issues an ioctl(2) on the root FS block device which turns
on recording of block reads (it records block
On Fri, 4 May 2001, Alexander Viro wrote:
ObProcfs: I don't think that walking the page tables is a good way to
compute RSS, especially since VM maintains the thing.
Well, the VM didn't always use to maintain the stuff it does now, so I bet
that most of the code is just old code that still
On Fri, 4 May 2001, Richard Gooch wrote:
Two of them: use less bloated shell (and link it statically) and
clean your rc scripts.
No, because I'm not using the latest bloated version of bash, and I'm
Umm... Last version of bash I could call not bloated was _long_ time
ago. Something
Alexander Viro writes:
On Fri, 4 May 2001, Richard Gooch wrote:
Two of them: use less bloated shell (and link it statically) and
clean your rc scripts.
No, because I'm not using the latest bloated version of bash, and I'm
Umm... Last version of bash I could call not bloated
On Fri, 4 May 2001, Richard Gooch wrote:
I don't bother splitting /usr off /. I gave up doing that when disc
became cheap. There's no point anymore. And since I have a lightweight
Yes, there is. Locality. Resistance to fs fuckups. Resistance to disk
fuckups. Easier to restore from tape.
Alexander Viro writes:
On Fri, 4 May 2001, Richard Gooch wrote:
I don't bother splitting /usr off /. I gave up doing that when disc
became cheap. There's no point anymore. And since I have a lightweight
Yes, there is. Locality. Resistance to fs fuckups. Resistance to
disk fuckups.
On Fri, 4 May 2001, Alan Cox wrote:
iso9660 alas doesn't allow you to do that. You can speed it up by reading
the entire file into memory rather than paging it in (or reading it in and
then executing it). iso9660 layout is pretty constrained and designed for
linear file reads
Note that
On Thu, 3 May 2001, Alan Cox wrote:
>
> > > discussion in itself), and there really are no valid uses for opening a
> > > block device that is already mounted. More importantly, I don't think
> > > anybody actually does.
> >
> > Actually I did. I might do it again :) The point was to get the
> > discussion in itself), and there really are no valid uses for opening a
> > block device that is already mounted. More importantly, I don't think
> > anybody actually does.
>
> Actually I did. I might do it again :) The point was to get the kernel to
> cache certain blocks in the RAM.
On Thu, 26 Apr 2001, Linus Torvalds wrote:
>
>
> On Thu, 26 Apr 2001, Alexander Viro wrote:
> > On Thu, 26 Apr 2001, Andrea Arcangeli wrote:
> > >
> > > how can the read in progress see a branch that we didn't spliced yet? We
> >
> > fd = open("/dev/hda1", O_RDONLY);
> > read(fd, buf,
On Thu, 26 Apr 2001, Linus Torvalds wrote:
On Thu, 26 Apr 2001, Alexander Viro wrote:
On Thu, 26 Apr 2001, Andrea Arcangeli wrote:
how can the read in progress see a branch that we didn't spliced yet? We
fd = open(/dev/hda1, O_RDONLY);
read(fd, buf, sizeof(buf));
Note
discussion in itself), and there really are no valid uses for opening a
block device that is already mounted. More importantly, I don't think
anybody actually does.
Actually I did. I might do it again :) The point was to get the kernel to
cache certain blocks in the RAM.
Ditto for
On Thu, 3 May 2001, Alan Cox wrote:
discussion in itself), and there really are no valid uses for opening a
block device that is already mounted. More importantly, I don't think
anybody actually does.
Actually I did. I might do it again :) The point was to get the kernel to
Hiya.
Linus Torvalds wrote:
> So anybody who depends on "dump" getting backups right is already playing
> russian rulette with their backups. It's not at all guaranteed to get the
> right results - you may end up having stale data in the buffer cache that
> ends up being "backed up".
>
> Dump
> or such. tar/cpio and friends don't deal properly with
> a. holes inside of files.
> b. hardlinks between files.
GNU tar handles both of these. (Not particularly efficiently in the
case of sparse files, but that's a minor issue in this case.) See -S flag.
Perhaps more importantly, for a
On Sat, Apr 28 2001, Albert D. Cahalan wrote:
> Linus Torvalds writes:
>
> > The buffer cache is "virtual" in the sense that /dev/hda is a
> > completely separate name-space from /dev/hda1, even if there
> > is some physical overlap.
>
> So the aliasing problems and elevator algorithm confusion
Martin Dalecki :
> tar/cpio and friends don't deal properly with
>
> a. holes inside of files.
> b. hardlinks between files.
>
??? GNU tar does both. The only thing it currently cannot handle is Not
Changing Anything: either atime or ctime _will_ be updated.
-
To unsubscribe from this list:
Martin Dalecki :
tar/cpio and friends don't deal properly with
a. holes inside of files.
b. hardlinks between files.
??? GNU tar does both. The only thing it currently cannot handle is Not
Changing Anything: either atime or ctime _will_ be updated.
-
To unsubscribe from this list: send the
On Sat, Apr 28 2001, Albert D. Cahalan wrote:
Linus Torvalds writes:
The buffer cache is virtual in the sense that /dev/hda is a
completely separate name-space from /dev/hda1, even if there
is some physical overlap.
So the aliasing problems and elevator algorithm confusion remain?
At
or such. tar/cpio and friends don't deal properly with
a. holes inside of files.
b. hardlinks between files.
GNU tar handles both of these. (Not particularly efficiently in the
case of sparse files, but that's a minor issue in this case.) See -S flag.
Perhaps more importantly, for a _robust_
Linus Torvalds writes:
> The buffer cache is "virtual" in the sense that /dev/hda is a
> completely separate name-space from /dev/hda1, even if there
> is some physical overlap.
So the aliasing problems and elevator algorithm confusion remain?
Is this ever likely to change, and what is with the
On Fri, Apr 27, 2001 at 09:52:19AM -0700, Linus Torvalds wrote:
>
> On Fri, 27 Apr 2001, Vojtech Pavlik wrote:
> >
> > Actually this is done quite often, even on mounted fs's:
> >
> > hdparm -t /dev/hda
>
> Note that this one happens to be ok.
>
> The buffer cache is "virtual" in the sense
On Fri, Apr 27, 2001 at 11:02:17AM -0700, LA Walsh wrote:
> Andrzej Krzysztofowicz wrote:
>
> > I know a few people that often do:
> >
> > dd if=/dev/hda1 of=/dev/hdc1
> > e2fsck /dev/hdc1
> >
> > to make an "exact" copy of a currently working system.
>
> ---
> Presumably this isn't a
Andrzej Krzysztofowicz wrote:
> I know a few people that often do:
>
> dd if=/dev/hda1 of=/dev/hdc1
> e2fsck /dev/hdc1
>
> to make an "exact" copy of a currently working system.
---
Presumably this isn't a problem is the source disks are either unmounted or
mounted 'read-only' ?
--
The
Linus Torvalds wrote:
> On Fri, 27 Apr 2001, Neil Conway wrote:
> >
> > I'm surprised that dump is deprecated (by you at least ;-)). What to
> > use instead for backups on machines that can't umount disks regularly?
>
> Note that dump simply won't work reliably at all even in 2.4.x: the buffer
Linus Torvalds wrote:
> Dump was a stupid program in the first place. Leave it behind.
Not quite Linus - dump/restore are nice tools to create for example
automatic over network installation servers, i.e. efficient system
images
or such. tar/cpio and friends don't deal properly with
a. holes
[ linux-kernel added back as a cc ]
On Fri, 27 Apr 2001, Neil Conway wrote:
>
> I'm surprised that dump is deprecated (by you at least ;-)). What to
> use instead for backups on machines that can't umount disks regularly?
Note that dump simply won't work reliably at all even in 2.4.x: the
On Fri, 27 Apr 2001, Vojtech Pavlik wrote:
>
> Actually this is done quite often, even on mounted fs's:
>
> hdparm -t /dev/hda
Note that this one happens to be ok.
The buffer cache is "virtual" in the sense that /dev/hda is a completely
separate name-space from /dev/hda1, even if there is
On Fri, Apr 27, 2001 at 09:23:57AM -0400, you [Alexander Viro] claimed:
>
>
> On Fri, 27 Apr 2001, Vojtech Pavlik wrote:
>
> > Actually this is done quite often, even on mounted fs's:
> >
> > hdparm -t /dev/hda
>
> You would need either hdparm -t /dev/hda or mounting the
> whole /dev/hda.
>
On Thu, Apr 26, 2001 at 01:08:25PM -0700, Linus Torvalds wrote:
> Note that I think all these arguments are fairly bogus. Doing things like
> "dump" on a live filesystem is stupid and dangerous (in my opinion it is
> stupid and dangerous to use "dump" at _all_, but that's a whole 'nother
>
1 - 100 of 169 matches
Mail list logo
