> This has many advantages.
>
> 1. does not harm compatibility with existing filesystems & kernels
> 2. can put the log on a tape
> 3. can put the log in non-volatile RAM
> 4. can use one fast disk as the log for a dozen slow disks
> 5. can run multiple logs for redundancy
6. Minimizes the performance impact of journaling on write performance.
Would be a good thing. I didn't do any quantitive measurements on this but
my feeling says that the two ``undestructibe'' filesystems I've worked
with (Solaris + Solstice Disksuite and IRIX's XFS) both have reduced write
performance with the log on the data disk. Especially the UFS thingy seems
to suffer.
> Point #3 would allow for some impressive TPC and NFS benchmark
> scores, without even breaking the benchmark reporting rules.
There is hardware option for Sun's named Prestoserve. It's probably named
something else nowadays but whatever, this is NVRAM used as backing store
just for NFS writes plus drivers which mainly deal with with crash
recovery. This things allows NFS write numbers to come significantly closer
to write performance on local disks. But then this usage of NVRAM is
completly different from filesystem logs, but can be combined.
All the good TPC numbers I know of were made on machines using raw disk
access, not filesystems, so they're not impacted by filesystem logs anyway.
> If you put the log on tape and started a second tape before the
> first one finished, you could keep changing tapes. You'd end up
> with a huge tape library that has a log of every filesystem change
> ever made. Add timestamps and user IDs for a solid audit trail.
No. You only want to guarantee metadata consistence and therefore only
need metadata logs. Data consistence is by it's nature application
stuff. And we don't want logs for such purposes, just for a performant
guarantee of data consistence.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu